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Abstract 

We  present  a  method  for  verifying  real-time  constraints  in  a  distributed,  coarse-grain  dataflow 
environment  starting  with  a  program  which  has  already  been  allocated  onto  a  machine.  The 
user  specifles  the  timing  of  each  module  together  with  real-time  constraints;  and  we  verify 
the  constraints.  To  deduce  program’s  timing,  the  user  specifies  all  possible  behaviors  of  each 
dataflow  module  and  assigns  timing  costs  to  each  module’s  behavior.  We  use  the  behavior 
and  timing  of  individual  modules  to  derive  a  data  independent  timing  model  for  the  entire 
prograim.  User  specifiable  constraints  include  conditioned  constraints  and  constraints  through 
non-deterministic  paths.  An  event-driven  verification  verifies  constraints.  We  justify  the  need 
for  an  event-driven  verification,  describe  design  issues,  and  offer  a  tagging  scheme  for  sharing 
state  among  multiple  verifications. 
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Chapter  1 

Introduction 


Many  computerized  systems  are  subject  to  strict  time  constraints.  Control  systems  in  the  oil 
logging  industry,  automated  manufacture,  space  exploration,  as  well  as  defense,  call  for  fast, 
time-bound  response.  If  a  delay  in  response  beyond  the  specified  time-bound  would  lead  to 
a  system  failure  (with  often  dire  consequences),  the  system  is  classified  as  a  hard  real  time 
system. 


1.1  Real-Time  Software 

The  needs  of  these  hard  real-time  systems  differ  from  the  common  needs  addressed  by  the 
standard  computing  environments.  Most  prograimming  languages  abstract  functional  behavior 
from  timing  considerations.  Most  operating  systems  and  network  protocols  offer  a  few  time 
boimd  services. 

This  lack  of  high-level  support  has  lead  to  many  ad  hoc  approaches.  Meiny  time-critical 
systems  have  been  implemented  at  assembly  level.  Higher  level  implementations  have  been 
tested  on  specific  prototypes  with  common  input  cases.  Others  have  been  subjected  to  stochastic 
simulations  insensitive  to  small  populations  amd  unstable  operating  conditions  -  the  essentials 
of  worst  case  verification.  Not  surprisingly,  such  solutions  have  led  to  high  development  costs 
and  unexpected  failures. 

In  contrast,  an  optimal  real-time  system  should  provide  a  ”ser  with  prograimming  ease  and 
predictability.  The  system  should  accept  a  high-level  specification  of  real  time  requirements 
and  verify  their  feasibility. 

Investigated  specification  approaches  vasy  from  integrated  program  specificatioi's  as  in  real¬ 
time  languages,  to  isolated  timing  specifications.  Of  the  programming  languages,  the  best 
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known  is  Ada  which  cillows  specification  of  relative  constraints.  More  thorough  treatment  of 
reed  time  concepts  can  be  found  in  research  languages  such  as  LUSTRE  12  ,  a  synchronous,  real 
time  dataflow  Icinguage.  Other  approaches  range  from  use  of  static  typing  to  specify  relative 
and  absolute  time  predicates  13;  to  the  extension  of  temporal  logic  to  model  states  and  events 
through  clock  ticks  14;. 

Wrification  efforts  vary  with  the  nature  of  timing  constraints.  Relative  timing  constraints 
enforce  sequencing  of  events  within  an  execution  and  can  be  verified  without  knowledge  of 
machine  speeds,  .\bsolute  timing  constraints  place  absolute  bounds  on  execution  latencies  and 
require  knowledge  of  hardware  timing.  They  are  typical  of  hard  real  time  systems. 

Research  in  verification  of  relative  time  constraints  has  met  with  much  success.  Formal 
specifications  such  as  those  based  in  temporal  logic  can  be  used  to  prove  Liveness  and  precedence 
relations. 

\'erification  of  absolute  constraints  has  generated  attention  at  two  different  levels,  at  the  low 
machine  level  and  at  the  high  specification  level.  At  machine  level,  commercial  projects  have 
successfully  bound  system  latencies.  Masscomp's  Real  Time  Unix  23',  for  instance,  binds  sys¬ 
tem  response  times  through  fixed  priority  scheduling  for  predictable  schedules,  through  memory 
locking  for  processing  free  of  paging  aind  swapping,  and  through  kernel  preemption  for  bound 
delay  of  real  time  processes  due  to  outside  system  requests. 

.A.t  higher  level,  few  of  the  formal  specification  methods  have  succeeded  in  providing  a 
clean  interface  to  the  low  machine  level  verification.  One  of  the  more  successful  approaches 
in  this  respect  has  been  Jahanian  and  Mok’s  real  time  logic  (RTL)  11  .  Their  logic  relies  on 
safety  assertions,  maximum  delays  along  each  module,  for  deadline  specification.  As  long  as  all 
assertions  are  met  by  the  underlying  machine,  an  absolute  constraint  is  feasible.  Such  assertions 
hide  synchronisation  and  contention  costs  md  correspond  to  worst  case  analysis  of  individual 
latencies  as  explored  by  Leinbaugh  «uid  Yamini  -5;. 

More  accurate  latency  bounds  can  be  achieved  through  direct  simulation.  However,  as 
Stankovic  1'  points  out,  this  approach  must  tackle  the  complexity  barrier.  For  all  but  the 
simplest  programs,  accuracy  must  be  sacrificed  to  lower  the  cost  of  computing  the  simulation. 
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1.2  Distributed  Real-Time  Software 


The  design  of  a  real-time  system  is  further  complicated  by  the  frequent  use  of  multiple  pro¬ 
cessors,  which  may  be  necessary  for  several  reasons.  First,  the  computing  power  of  a  single 
proccs:>or  may  not  be  enough  to  meet  hard  real  time  constraints.  Second,  an  application  may 
require  different  processor  types.  .\nd  third,  acquired  data  may  need  to  be  processed  at  different 
locations. 

As  a  result,  an  optimal  real  time  system  should  provide  specification  and  verification  merii- 
ods  within  a  distributed,  heterogeneous  environment.  This  requirement  heightens  *he  need  for 
modular  timing  specifications.  It  further  introduces  the  need  for  verifiable  real-time  comnnuii- 
cation  and  its  specifications. 

1.3  Resource  Allocation 

.\  further  complication  in  the  design  of  a  hard  real  time  system  is  the  need  for  an  optimized, 
predictable  resource  allocation  method.  A  predictable  aiUocation  schedule  is  essential  to  absolute 
constraint  verification.  While  easy  to  achieve,  predictability  has  not  been  required  of  many 
existing  schedulers  23’. 

A  reasonably  optimized  allocation  method  is  essential  to  meeting  absolute  constraints.  In 
an  optimal  real-time  system,  one  would  like  an  automated  allocator  to  arrive  at  an  optimal 
allocation  schedule.  Such  an  allocator  would  be  NP  complete  even  for  the  much  simpler  case 
of  two  identical  processors  executing  independent  tasks  with  no  communication  overhead  9  . 
.A.5  a  result,  all  practical  scheduling  algorithms  within  a  multiple  processor  environment  rely 
on  heuristics.  The  most  common  approach  is  a  back-tracking  branch  and  bound  search  within 
a  simulation.  Simplified  versions  include  heuristic  transformation  of  a  program  graph  onto  a 
m'lltiple  processor  graph,  and  an  independent  allocation  of  computation  paths  beginning  with 
the  most  critical  path.  Several  conflicting  goals  in  these  approaches  are  the  minimization  of 
complexity,  the  preservation  of  a  global  program  view,  and  the  consideration  of  ciU  relevant 
time  costs. 
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1.4  Synopsis 

In  this  thesis,  we  attempt  to  develop  a  technique  for  dealing  with  real  time  constraints  in  the 
context  of  a  device  control  and  data  acquisition  system  for  oil  well  logging.  We  narrow  oxir 
attention  to  periodic  progreims  and  steirt  with  an  existing  software  architecture,  the  Stream 
Machine  ,17].  We  augment  and  simplify  the  computational  model  to  achieve  a  simple  timing 
specification.  We  amalyze  constraints  and  check  feasibility  within  an  allocation  scheme. 

The  content  of  this  thesis  tracks  the  progress  of  its  project.  Chapter  one  introduces  the 
issues  and  complexity  in  real  time  systems  and  points  out  related  work.  Chapter  two  presents 
initial  thoughts  and  goals  behind  this  project.  Chapter  three  describes  the  tau'geted  applica¬ 
tions  and  the  inherited  programming  environment,  the  Stream  Machine.  Chapter  four  presents 
a  specification  method  for  the  envisioned  recd-time  costs  in  our  computational  model.  It  out¬ 
lines  our  approach  towards  real-time  specification  and  implements  this  approach.  Chapter  five 
presents  a  specification  method  for  the  envisioned  real-time  constraints.  Chapter  six  offers  a 
verification  method  for  the  developed  constraint  specifications.  It  outlines  the  initial  assump¬ 
tions,  and  describes  and  optimizes  our  verifier.  Finally,  Chapter  seven  of  the  thesis,  draws 
results  and  lessons  from  the  project  and  suggests  areas  of  further  work. 
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Chapter  2 


Project’s 


Background 


2.1  Motivation 

The  motivation  for  this  work  came  from  the  increasing  need  for  feedback  control  in  acquisition 
of  oil  well  data.  On  site  acquisition  and  interpretation  of  oil  well  data  is  the  main  service  of  the 
Schlumberger  Wireline  Testing  and  Service  Companies.  Schlumberger  acquires  and  interprets 
data  for  clients  throughout  the  world.  AH  acquisition  is  done  with  tools  and  computational 
resources  contained  within  a  highly  customized  vehicle,  the  Schlumberger  truck.  Upon  request, 
the  regional  Schlumberger  branch  dispatches  a  truck  to  a  well  site,  lowers  appropriate  sensory 
tools  into  the  well  and  acquires  data  through  attached  on  board  computers. 

It  is  essential  that  well  data  acquisition  be  fast  and  reliable.  The  acquisition  of  data  halts 
the  production  of  oil  within  a  well.  As  a  result,  the  acquisition  must  be  fast  in  order  to  minimize 
the  lost  revenue  and  operationcd  expense  of  an  idle  well.  The  malfunction  of  the  sensory  tools 
lowered  into  the  well  or  of  the  computational  environment  can  cause  delay  and  loss  or  dcimage 
of  expensive  tools.  As  a  result,  the  acquisition  must  be  highly  reliable.  Finally,  the  acquired 
data  must  be  accurate  and  relevant  to  further  interpretation. 

The  relevance,  acctiracy,  and  reliability  of  the  acquisition  process  can  be  enhcinced  through 
real-time  feedback  to  the  sensory  tools.  Real-time  feedback  can  increase  the  accuracy  of  acquired 
data  as  the  tool  adjusts  its  speed,  resolution,  emd  other  parameters  based  on  feedback  data. 
Similarly,  real-time  feedback  can  improve  relevance  of  acquired  data  as  the  tool  zooms  in  on 
critical  regions  of  the  weU  and  reacts  quickly  to  any  aberrations.  Finally,  real-time  feedback 
can  improve  reliability  through  real  time  monitoring  of  tool  conditions  and  prompt  recovery  of 
an  endangered  tool. 
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2.2  The  Problem 


2.2.1  Feedback 

Our  process  of  generating  feedback  consists  of  three  stages.  In  stage  one,  we  acquire  data 
from  a  periodic  source.  In  stage  two,  we  feed  the  acquired  data  to  an  application  program 
and  compute  feedback  data.  Finally  in  stage  three,  we  forward  feedback  data  to  its  target. 
Figure  2.1  illustrates  the  feedback  process. 


Source 


_ 5 

t _ 

Application  Program 

_ 2 

£ _ 

Stage  1 


Stage  2 


Stage  3 


Target 


Figure  2.1:  The  Three  Stages  of  a  Feedback  Process. 


Figure  2.2  illustrates  the  feedback  process  within  our  present  domaun.  In  our  present  domain, 
the  periodic  source  of  data  is  a  sensory  tool  lowered  into  an  oil  well.  Data  acquired  by  the  tool’s 
downhole  processor  propagates  up  the  well  hole  into  the  Schlumberger  truck.  On  board  the 
truck,  the  data  is  accepted  by  a  dedicated  acquisition  processor.  The  acquisition  processor 
communicates  with  an  on  board  workstation  via  shared  memory.  Two  on  board  workstations 
may  cooperate  in  computing  feedback  data.  The  target  of  feedback  data  is,  again,  a  sensory 
tool  within  the  well. 

We  expect  our  domain  to  evolve  as  feedback  requirements  increase  with  new  sensory  tools 
and  as  technology  progresses.  Specifically,  we  expect  to  see  more  computing  power  on  the 
Schlumberger  truck.  Multiple  and  specialized  processors  and  coprocessors  will  absorb  the  in¬ 
creased  computation2d  load.  As  the  temperature  and  pressure  resistance  of  VLSI  circuits  in¬ 
creases,  vre  also  expect  to  see  part  of  the  computing  stage  shifting  from  the  truck  into  the  well. 
A  processor  within  the  sensory  tool  will  reduce  the  data  bandwidth  between  the  tool  and  the 
truck  and  shift  low-computation  feedback  control  into  the  tool. 
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Figure  2.2:  Resources  Utilized  by  a  Feedback  Process  within  our  Domain. 

2.2.2  Real-Time 

The  relevcince  of  feedback  information  varies  with  time.  For  exeimple,  a  feedback  directive  to 
recover  a  tool  becomes  irrelevcint  once  the  tool  has  been  lost.  Similarly,  a  feedback  adjustment 
of  a  measurement  technique  becomes  irrelevant  once  the  measurement  conditions  have  chzuiged. 
To  achieve  our  aims,  we  must 

1.  constrain  the  latency  of  each  feedback  process,  and 

2.  gueirantee  to  meet  imposed  constraints. 

To  guaraintee  imposed  constraints,  we  must  implement  each  feedback  process  and  verify  that 
our  implementation  meets  the  imposed  constraints.  To  implement  a  feedback  process,  we  must 
assign  resources  to  each  of  the  three  stages  of  a  feedback  process  and  write  the  application 
program  of  stage  2. 

One  way  to  verify  a  feedback  latency  constraint  is  to  rim  and  time  our  feedback  process 
implementation.  If  the  process  completes  within  the  constrained  time,  the  constraint  has  been 
met.  However,  this  meeting  of  a  constraint  does  not  reflect  on  future  invocations  of  this  im¬ 
plementation.  For  one,  the  latency  of  each  invocation  may  be  data  dependent.  Different  input 
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data  may  require  different  computation  and  propagate  through  the  feedback  process  at  different 
speed.  To  guarantee  a  constraint,  we  would  need  to  rim  and  time  our  implementation  for  ail 
possible  input  values  -  an  unlikely  prospect. 

Moreover,  the  individual  latencies  within  an  implementation  may  vary.  The  latency  through 
a  communication  chaimel,  for  instaince,  may  depend  on  the  instantaneous  contention  for  that 
channel.  The  latency  of  code  execution  may  depend  on  the  momentary  number  of  system  call 
interrupts.  While  all  individual  latencies  within  a  feedback  process  must  have  a  finite  upper 
boimd  to  gutirantee  a  real-time  constraint,  a  single  run  of  the  feedback  prncpss  is  unlikely  to 
capture  the  worst  case  scentirio. 

2«3  GohIs 

The  goal  of  this  project  is  to  design  a  prototype  verification  system  for  real-time  feedback 
processes  in  the  Schlumberger  oil  well  logging  context.  We  start  with  the  present  feedback 
process  model  -  the  Stream  Machine.  The  goal  of  our  system  is  to  integrate  into  this  model 

1.  specification  of  implementation’s  timing, 

2.  specification  or  implementation’s  real-time  constraints,  and 

3.  verification  of  implementation’s  constraints. 
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Chapter  3 

Project’s  Environment 


This  project  builds  on  top  of  cin  existing  application  domain  and  an  existing  feedback  process 
model.  The  following  chapter  describes  both  the  application,  the  Schlumberger  well  acquisition 
software,  and  the  model,  the  Stream  Machine.  Moreover,  the  chapter  gives  excunples,  extracts 
their  characteristics,  and  formulates  a  representative  problem  used  through  the  remainder  of 
this  thesis. 


3.1  Stream  Machine  (SM) 

The  computational  model  employed  on  the  Schlumberger  trucks  is  the  Stream  Machine  (SM). 
The  SM  imlements  a  computational  model  on  top  of  a  distributed  computer  network.  An  in¬ 
stance  of  an  SM  implementation  consists  of  a  program  description,  a  machine  description,  and 
an  cdlocation  description.  An  SM  program  consists  of  buffered  communicating  sequential  pro¬ 
cesses.  A  machine  consists  of  distributed  hardware  resources  such  as  those  on  the  Schlumberger 
truck.  And  an  allocation  maps  program  components  -  processes  and  streams,  onto  the  machine 
resources  -  the  hardware. 

3.1.1  Program 

A  program  consists  of  a  set  of  processes,  or  modules,  and  a  set  of  streams.  Modules  communicate 
via  tokens  along  streams.  Each  module  interleaves  a  finite  number  of  suspending  and  executing 
states.  Suspended,  a  module  awaits  a  token  along  a  given  input  stream.  Alternately,  a  module 
may  await  a  token  along  one  of  several  input  streams,  thus  introducing  nondeterminism.  On  the 
token’s  arrived,  a  module  consumes  the  eirrived  token,  and  executes.  While  executing,  a  module 
may  produce  token(s)  along  any  of  its  output  streams.  Each  stream  accepts  tokens  from  exactly 
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one  producer  module  and  forwards  these  tokens  to  one  or  more  consumer  modules.  Tokens  are 
guaranteed  to  reach  consumer  modules  in  the  order  in  which  they  were  generated. 

Figure  3.1  shows  a  high-level  representation  of  a  module.  This  module  has  two  input 
streams,  1  ^lnd  3,  and  two  output  streams,  2  zmd  4. 


si  s2 


33  s4 

Figure  3.1;  A  Box  and  Arrow  Representation  of  an  3M  Module,  M. 


Figure  3.2;  A  Finite  State  Representation  of  an  SM  Module,  M. 

Figure  3.2  gives  a  more  detailed  view  of  this  module.  It  shows  its  internal  finite  state 
behavior.  In  its  initijil  state,  this  module  awaits  a  token  along  stream  si.  It  consumes  the 
arrived  token  along  stream  si  and  executes  producing  one  token  along  stream  s2.  When  done 
executing,  the  module  awaits  a  token  along  stream  s3.  It  consumes  the  arrived  token  along 
stream  s3  and  executes.  During  this  execution,  the  module  may  produce  a  token  <dong  stream 
s4  and,  eventually,  return  to  its  initial  state.  Alternately,  the  module  may  produce  no  tokens 
and  return  to  its  third  state,  aw2utmg  a  token  along  stream  s3. 
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Through  the  rest  of  this  thesis,  we  will  represent  program  modules  either  with  finite  state 
diagrams  such  as  that  of  Figure  3.2,  or,  mere  abstractly,  with  box  and  arrow  diagrams  such  as 
that  of  Figure  3.1 

Assumptions 

In  order  to  simplify  our  specification,  we  restrict  the  original  Stream  Machine  model.  The 
Stream  Machine  model,  as  described  in  [17],  is  a  model  of  buffered  communicating  sequential 
processes  (CSP).  Stream  reads  and  writes  are  interspersed  throughout  each  module  leading  to 
many  module  states.  In  each  state,  a  module  is  either  executing  with  interspersed  stream  writes 
or  waiting  to  read  from  one  of  its  input  streams.  Figure  3.2  showed  an  example  of  possible 
module  states. 

We  narrow  this  model  by  constraining  each  program  niudul,,  to  nave  only  two  states  -  one 
await  state  and  one  execute  state.  This  constraint  takes  us  from  a  CSP  model  to  a  coarse-grain 
dataflow  model.  Here  each  module  waits  to  read  from  all  of  its  input  streams  at  once.  It  then 
executes  with  interspersed  stream  writes. 

Figure  3.3  reformulates  the  module  of  Figure  3.2  into  two  coarse-grain  dataflow  modules. 
This  conversion  splits  the  original  CSP  module  along  each  await  state.  Note  that  arrows 
indicating  control  flow  in  Figure  3.2  have  now  turned  into  streams.  They  have  become  streams 
5,  6,  and  7.  These  new  streams  enforce  the  original  flow  of  control  between  what  have  now 
become  two  modules. 

We  retain  a  nondeterministic  merge  module  present  in  the  origined  CSP  model  as  our  means 
of  introducing  nondeterminism. 

Unlike  in  the  original  CSP  model,  in  the  dataflow  model,  a  module  cannot  merge  tokens 
from  several  input  streams  onto  a  single  output  stream  in  a  deterministic  order.  A  standard 
mechanism  for  merging  tokens  in  a  given  order  is  to  specify  the  desired  order  along  a  special 
input  stream,  the  Select  stream.  The  merge  module  awaits  a  token  along  the  Select  stream  and 
then,  based  on  the  token’s  value,  awaits  a  token  along  one  of  its  input  streams.  A  dataflow  mod¬ 
ule  with  a  single  await  state  cannot  achieve  this  behavior.  It  cannot  decide  which  input  stream 
to  read  next  based  on  the  value  read  adong  another  input  streaun.  We  complete  our  coairse-grain 
dataiflow  model  by  adding  a  special  module  which  allows  this  behavior  -  the  deterministic  merge 
module. 

The  deterministic  merge  module  d«tennin«8  the  order  in  which  tokens  merge  onto  am 
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FigTore  3.3:  A  CSP  Module,  M,  Converted  into  Two  Dataflow  Modules,  Ml  and  M2. 

output  stream  based  on  values  along  the  Select  stream.  Compare  the  simplest  merge  module 
with  the  simplest  deterministic  merge  module  (Figme  3.4).  Say  one  token  arrives  along  each 
input  stream  sometimes  dming  the  program.  In  caise  of  the  merge  module,  the  order  in  which 
the  two  input  tokens  wiU  merge  onto  the  output  stream  is  not  known.  It  depends  on  the  relative 
arrival  time  of  the  two  input  tokens.  Whichever  input  token  arrives  first  will  merge  first.  In 
case  of  the  deterministic  merge  module  the  order  is  known  regardless  of  tokens’  arrival  time. 
The  order  is  determined  by  tokens  along  a  third  input  stream,  the  Select  stream.  Tokens  adong 
this  stream  identify  the  input  stream  from  which  to  merge  next. 

3.1.2  Machine 

A  machine  consists  of  a  set  of  processors  and  a  set  of  channels.  Both,  the  processors  and 
the  channels  are  heterogeneous.  Processor  performance  is  described  by  the  processor’s  rate 
of  instruction  execution,  and  by  the  processor’s  contention  protocol.  Channel  performance  is 
described  by  the  channel’s  rate  of  packet  propagation,  it’s  latency  of  propagating  a  packet,  the 
size(s)  of  a  packet,  and  the  charmel’s  contention  protocol.  Again,  we  represent  processors  and 
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Figure  3.4:  Comparison  of  a  Merge  Module  and  a  Deterministic  Merge  Module. 

chcirmels  with  box  and  eirrow  diagrams  such  as  that  of  Figure  3.5.  The  machine  in  Figure  3.5 
consists  of  two  processors,  PI  and  P2,  communicating  via  a  bidirectional  channel,  C.  Each 
box  is  a  processor;  each  multi-  directional  arrow  is  a  channel. 

C 


Figure  3.5:  A  box  and  arrow  representation  of  a  simple  SM  machine. 


3.1.3  Allocation 

s5  s6 

C 

Figure  3.6:  A  Box  and  Arrow  Representation  of  iin  SM  Allocation. 

An  allocation  allocates  machine  resources  to  progr£im  components.  We  limit  our  attention  to 
static  zdlocations.  Each  module  is  assigned  to  one  processor.  Each  stream  is  assigned  to  a  set 
of  processors  and  channels.  We  represent  allocations  with  labeled  box  and  tirrow  diagrams  such 
as  that  of  Figure  3.6.  In  Figure  3.6,  the  modules  and  streams  of  Figure  3.3  have  been  allocated 


Ml  si  32  s5  s6 


PI 


M2  83  s4  sS  s6  sT 
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onto  the  machine  of  Figure  3.5. 

Since  machine  resources  are  heterogeneous,  the  performance  of  each  program  component 
depends  on  its  allocation.  For  modules,  the  latency  of  each  execution  state  depends  on  the 
processor  allocation  of  that  module.  Moreover,  since  specialized  processors  optimize  certain 
computations,  module’s  execution  latencies  do  not  scale  with  processor’s  rate  of  instruction 
execution.  Consider  a  vector  processor,  for  instance;  although  its  optimal  rate  of  instruction 
execution  may  be  ten  times  that  of  a  general  processor,  a  module  of  scalar  code  will  not  execute 
ten  times  faster.  As  a  result,  the  number  of  high  level  instructions  within  a  module  is  insufficient 
to  predict  module  performance  under  different  allocations. 

For  streams,  the  propagation  latency  of  each  token  along  a  stream  depends  on  the  channel 
and  processor  allocations  of  that  streami.  Each  channel  and  processor  may  accept  packets  of 
limited  length.  The  latency  of  a  token  thus  becomes  the  latency  of  its  packets.  Moreover,  the 
time  to  propagate  a  token  along  a  chamnel  may  Vciry  with  each  channel.  The  time  to  dispatch  an 
arrived  or  departing  packet  may  vary  with  each  processor.  For  simplicity’s  Scdce,  we  will  assume 
in  «di  further  discussion  that  each  token  maps  onto  exactly  one  packet.  This  assumption  simply 
removes  a  multiplication  factor  from  our  discussion. 

Aside  from  individual  components’  performance,  the  performamce  of  the  entire  program  also 
depends  on  an  allocation.  It  depends  on  the  specific  allocations  to  each  resource  and  on  the 
scheduling  method  along  each  resource.  Miiltiple  allocations  to  a  resource  may  cause  contention, 
degrading  the  progreim’s  performance.  The  resource’s  scheduling  method  can  moderate  this 
performance  degradation  by  favoring  time-critical  tasks. 

Allocation  Constraints 

The  process  of  tillocating  a  program  onto  a  machine  is  limited  by  three  types  of  constraints: 
program  topology  constraints,  machine  capacity  constraints,  and  dedicated  resource  constraints. 
AU  three  types  of  constraints  must  be  satisfied  in  order  for  a  program  to  execute  to  completion 
and  produced  desired  results. 

Program  Topology  Constraints  These  constraints  insure  that  communicating  processes 
will  be  able  to  commvmicate.  To  achieve  this,  any  two  modules  which  communicate  via  a  stream 
must  be  allocated  onto  a  single  processor  or  onto  two  processors  cormected  by  a  sequence  of 
chzmnels  amd  intermediate  processors. 
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Machine  Capacity  Constraints  These  constraints  insure  that  the  limits  of  each  machine 
component  are  not  exceeded.  To  achieve  this,  the  load  on  each  processor  must  not  exceed  the 
capacity  of  that  processor.  The  load  on  each  channel  must  not  exceed  the  capacity  of  that 
channel. 

The  load  on  a  processor  can  be  determined  by  scaling  all  module  execution  latencies  and 
all  packet  forwarding  latencies  eilong  the  processor  by  their  frequencies.  Similarly,  the  load  on 
a  chaimel  can  be  determined  by  scaling  all  packet  propagation  latencies  along  the  channel  by 
their  frequencies.  Finding  these  frequencies  is  part  of  an  implementation  specification,  one  of 
the  major  gocds  of  our  project. 

Dedicated  Resource  Constraints  These  constraints  limit  the  set  of  available  mappings. 
They  limit  the  allocation  of  a  given  module  to  certain  processors.  This  limitation  is  necessary  for 
modules  which  explicitly  make  use  of  certain  resources.  For  instance,  a  module  which  displays 
data  on  the  user's  screen  must  have  access  to  that  screen.  .4  module  which  retrieves  data  from 
a  sensory  tool  must  have  access  to  that  tool. 

Real-Time  Constraints 

The  above  three  constraints  gucirantee  that  an  allocated  program  will  run  to  completion  and 
produce  desired  results.  They  do  not,  however,  address  the  real-time  behavior  of  produced 
results.  To  address  timing  properties,  we  must  fxirther  constrain  an  allocation.  We  place  a 
time  limit  on  the  propagation  of  certeim  tokens  from  the  creation  of  token(s)  by  the  source 
moduie(s)  to  the  arrival  of  the  corresponding  feedback  token(s)  to  the  target  module(s).  .4 
data  independent  specification  of  this  propagation  process  is  the  major  component  of  a  real-time 
constraint  spedfrcat'on,  another  major  gocd  of  our  project. 


3.2  Examples 

Many  progrcims  with  retd-time  constraints  are  currently  in  use  or  mider  consideration  by 
Schlumberger,  with  many  more  anticipated  in  the  future.  We  give  two  realistic  examples. 
For  future  reference,  we  fiuther  develop  a  sample  example  encompassing  the  characteristics  of 
the  previous  two. 
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3.2.1  Tool  Arm  Attachment 


The  first  example  is  that  of  anchoring  the  arm  of  a  tool,  the  S.A.T^  tool,  to  the  wall  of  a  well. 
This  example  has  been  extensively  cincilyzed  in  TSh  The  tool  consists  of  a  tester  with  geophones 
for  measuring  seismic  vibration  and  an  arm  for  locking  the  tool  into  the  borehole.  There  is  a 
pressure  sensor  on  the  arm  for  detecting  when  the  arm  is  pressing  agaunst  the  borehole  well 
(Figure  3.7). 

The  movement  from  the  center  of  the  well  towards  a  wall  of  the  well  is  controlled  by  feedback 
from  an  application  progTcim  outside  the  well.  The  program  responds  to  two  streams  of  data 
from  the  tool: 

Distance  Stream  The  distance  stream  sends  up  tokens  describing  the  distance  of  the  arm  tip 
from  the  center  of  the  well. 

Pressure  Stream  The  pressure  stre^im  sends  up  tokens  describing  the  pressure  on  the  tip  of 
the  arm. 

Figure  3.8  shows  our  implementation  diagram  for  the  SAT  program.  Here,  the  Extension 
module  accepts  a  token  from  the  Distance  stream  and  decides  whether  the  arm  has  overex¬ 
tended.  If  so.  the  module  forwards  a  token  to  the  Merge  module.  .Another  module,  the 
Anchorage  module,  accepts  a  token  from  the  Pressure  streeim  and  decides  whether  the  arm 
has  anchored  to  a  wall.  If  so,  the  module  forwards  a  token  to  the  Merge  module. 

A  Merge  module  awaits  a  value  along  either  one  of  its  two  input  streams.  When  the  Merge 
module  receives  a  token  along  the  Anchored?  stream,  it  turns  off  power  to  the  anchored  tool 
and  informs  the  Extension  and  Anchorage  modules.  WTien  the  Merge  module  receives  a  token 
along  the  OverExtended?  stream,  it  turns  off  power  to  the  overextended  tool  and  Informs  the 
Extension  and  Anchorage  modules. 

Notice  that,  in  its  await  state,  the  Merge  module  awaits  a  token  along  any  one  of  multiple 
streams.  .A.S  a  result,  the  Merge  module  introducps  nondeterminism  into  our  program.  It  is  a 
nondeterministic  merge  module. 

There  are  two  timing  constraints  on  this  program; 

•  Given  a  token  on  the  Pressure  stream,  the  corresponding  token  on  the  PowerOff .  if  any, 
must  arrive  back  within  a  time  limit  sufficient  to  prevent  damage  to  the  arm  from  pressing 
against  the  wall. 

'  Mark  of  Schlumberger 
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Figure  3.7:  An  Overextended  Arm  and  an  Anchored  Arm. 


Figure  3.8:  SAT  Program  Diagram. 


•  Given  a  token  on  the  Distance  stream,  the  corresponding  token  on  the  PowerOf  f  stream, 
if  any,  must  airrive  back  within  a  time  limit  sufficient  to  prevent  damage  to  the  arm  from 
overextension. 

3.2.2  SLT-L  Measurement 

A  second  exaniple  of  a  read-time  program  is  th?.*'  of  acquiring  data  with  the  SLT-L^  tool.  This 
tool,  again,  consists  of  a  tester  lowered  into  the  well.  The  tester  measures  the  time  required 
for  a  soimd  wave  to  move  a  certain  distance  through  the  rock  formation.  The  measurement  is 
made  by  using  a  transmitter  to  generate  a  brief  sound  and  a  receiver  to  detect  the  arrival  of 
sound  as  it  propagates  through  the  formation.  The  receiver  measures  the  signal’s  amplitude 
within  a  time  window  that  begins  after  the  sound  is  generated. 

Figure  3.9  shows  a  sound  wave  in  response  to  soimd  impulse  at  stimulus  time.  The  sound 
wave  propagates  to  the  receiver  trams  it  time  after  its  generation  by  the  transmitter.  The 
sound  wave  is  measured  within  a  sliding  gate  time  window.  The  sliding  gate  window  is 
offset  from  the  stimulus  time  by  a  variable  time  offset. 

The  quality  of  the  measurement  is,  again,  maintained  by  feedback  from  an  application 
program  outside  the  well.  The  software  modules  respond  to  two  streams  of  data  from  the  tool: 

Maximum  Response  Amplitude  Stream  The  cunplitude  stream  sends  up  tokens  describ¬ 
ing  the  maximum  amplitude  of  the  response  sigrsd. 

Signal  Transit  Time  Stream  The  transit  time  stream  sends  up  tokens  describing  the  offset 
of  the  maximum  amplitude  response  from  the  stimulus. 

Figure  3.10  gives  an  implementation  of  the  SLT-L  program.  The  Tool  module  in  this 
program  is  allocated  onto  the  tool  processor  of  Figure  2.2.  It  provides  a  periodic  source  of 
input  do'ta  amd  is  the  target  of  feedb2M:k  data.  The  Controller  module  is  allocated  onto  the 
acquisition  processor  of  Figure  2.2.  It  accepts  a  packet  of  data  from  the  tool,  separates  it  into 
the  maxinium  signal  amplitude  and  the  signal  transit  time,  cind  forwards  these  to  stream  2  and 
stream  3  respectively.  The  Controller  module  tdso  accepts  feedback  data  from  streams  6  and 
7  and  forwards  these  to  the  tool. 

The  remaining  three  modules  of  Figure  3.10  implement  the  feedback  computation  process. 
The  AmplitudeToGain  module  adjusts  receiving  filter’s  g£un  based  on  the  maximum  detected 
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Figiire  3.9:  SLT-L  Sound  Wave. 


Figure  3.10:  SLT-L  Program  Diagram. 
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amplitude  of  the  signal.  The  Trans itToStartTime  module  adjust  the  starting  time  of  the 
sUding  gate  window  based  on  the  transit  time  of  the  previous  signal.  In  addition,  the  ToUser 
module  processes  four  consecutive  transit  time  measurements  and  outputs  the  result  to  the 

user. 


Figure  3.11:  Diagram  of  an  Optimized  SLT-L  Program. 


In  order  to  relax  the  read  time  constraint  on  feedback  propagation,  we  present  an  optimized 
implementation  of  the  SLT-L  program  (Figure  3.11).  In  this  implementation.  The  feedback 
data  is  computed  in  one  of  four  ways  corresponding  to  different  transmitter/receiver  pairs.  The 
Selector  module  interleaves  between  the  four  different  ways  to  compute  feedback.  In  any  one 
cycle,  it  forwards  the  maximum  signed  amplitude  to  the  next  AmplitudeToGain  module.  It 
also  forwzirds  the  signal  transit  time  to  the  corresponding  TransitToStartTime  module.  In 
addition,  all  TransitToStartTim*  modides  forward  the  computed  start  time  to  the  ToUser 
modules.  The  ToUser  modules  process  four  consecutive  measurements  and  forward  the  result 

to  the  user. 

This  implementation  is  identical  to  that  of  Barstow  in  [16].  The  implementation  overlaps 
the  computation  of  four  feedback  values.  The  four- way  interleaving  of  feedback  computation 
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lessens  the  real  time  feedback  constrcunt.  Each  amplitude  and  transit  time  measurement  can 
be  used  to  adjust  the  gain  and  start  time  of  the  fourth  next  measurement  instead  of  the  very 
next  one.  There  tire  two  resulting  timing  constraints  on  the  optimized  SLT-L  program: 

•  Given  a  token  on  the  meiximum  response  amplitude  stream,  strecim  1,  the  corresponding 
token  on  the  filter  gain  stream,  stream  27,  must  arrive  back  in  time  to  adjust  the  gadn  of 
the  collecting  filter  for  the  fourth  next  measurement. 

•  Given  a  token  on  the  transit  time  stream,  stream  2,  the  corresponding  token  on  the  sliding 
gate  start  time  streeim,  stream  28,  must  arrive  back  in  time  to  adjust  the  stairt  time  for 
the  fourth  next  measurement. 

3.2.3  Sample  Program 


Figure  3.12:  SAMPLE  Program. 


Finally  we  present  an  artificial  example  program,  SAMPLE,  that  is  characteristic  of  our  domain 
and  will  be  used  throughout  this  thesis.  Figure  3.12  shows  the  program  diagram  of  SAMPLE. 
In  this  section,  we  give  an  informal  description  of  SAMPLE’S  behavior.  A  detailed  description 
will  follow  in  Table  4.3. 

SAMPLE  acquires  data  with  a  hypothetical  tool.  As  before,  the  tool  is  a  tester  lowered  into 
a  well.  SAMPLE  monitors  the  performance  of  the  tool,  initiating  tool  recovery  if  necessary.  At 
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the  same  time,  SAMPLE  analyses  acquired  data.  Similarly  to  the  SLT-L  program,  SAMPLE 
adjusts  tool’s  measurement  pcirameters  based  on  analyzed  data.  Moreover,  SAMPLE  forwards 
analyzed  data  for  further  analysis,  storage,  and  immediate  display. 

More  specifically,  SAMPLE  provides  two  types  of  feedback  to  the  tool  through  the  Acquisition 
module.  A  periodic  feedback  signaJ  from  the  parameter  adjusting  segment  of  SAMPLE  controls 
the  tool  behavior.  An  emergency  feedback  signal  from  the  performance  monitoring  segment  of 
SAMPLE  recovers  the  tool  in  case  of  abnormality. 
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Figure  3.13:  The  Segment  of  SAMPLE  Program  Responsible  for  Performance  Monitoring  eind 
Possible  Tool  Recovery. 

Figure  3.13  shows  the  segment  of  SAMPLE  program  responsible  for  performance  monitor¬ 
ing  and  possible  tool  recovery.  Two  modules,  Honitorl  emd  Nonitor2,  monitor  two  separate 
aspects  of  the  tool’s  performmce.  Each  of  these  modules  evaluates  acquired  data  for  certain 
abnormal  conditions  and  notifies  the  MonitorN«rg«  module  of  detected  abnormalities.  Based 
on  input  from  both  modules,  the  MonitorMerg®  module  decides  whether  to  generate  an  emer¬ 
gency  tool  recovery  signal.  Because  of  Monitorl’s  long  latency,  each  Monitor  module  only 
evaluates  every  other  data.  The  MonitorS«l6ct  module  intennittently  forwwds  data  to  the 
Monitorl  module  and  to  the  Honitor2  module.  Correspondingly,  the  HonitorMerg®  module 
intermittently  merges  data  from  the  Monitorl  module  or  from  the  Monitor2  module. 

To  illustrate  the  content  of  a  module.  Figure  3.14  shows  a  possible  code  routine  which 
comprises  the  body  of  the  Monitorl  module.  We  will  return  to  this  routine  in  the  next  chapter. 

Figure  3.15  shows  the  segment  of  SAMPLE  program  responsible  for  adjustment  of  tool’s 
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data  =  read(#ll); 
if  (data  <=  42) 

srite(#12,  “OK"); 
else 

i  =  0; 

vhile  (data  >  42)  and  (i  <  100) 
data  =  data  +  old-data [i] ; 
i  =  i  +  1 ; 

Brite(#12,  data/i); 
update-old-data(data,  old-data); 


Figrire  3.14:  Source  Code  for  SAMPLE’S  Honitorl  Module. 
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Figiire  3.15:  The  Segment  of  SAMPLE  Program  Responsible  for  Adjustment  of  Tool’s  Mea¬ 
surement  Parameters. 
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measurement  parameters.  The  ModelSelect  module  evaluates  incoming  data.  Depending  on 
data  value,  the  ModelSelect  module  forwzirds  either  one  token  to  the  oil  model  or  two  tokens 
to  the  sand  model  for  further  evaluation.  Simultaneously,  the  ModelSelect  module  informs 
the  ModelMerge  module  of  its  model  choice  along  stream  8.  Within  the  oil  model,  data  flows 
from  the  Oill  module  to  the  0il2  module.  The  0112  modxile  sends  evaluated  data  to  the 
ModelMerge  module  and  update  information  to  the  preceding  Oill  module.  Within  the  sand 
model,  two  tokens  invoke  the  Seind  module.  After  each  invocation,  the  Semd  module  forwards  a 
token  to  the  ModelMerge  module.  The  ModelMerge  module  merges  incoming  tokens  from  the 
two  models  in  the  order  specified  by  the  ModelSelect  module’s  directives. 

Figure  3.15  illustrates  a  common  use  of  deterministic  merge  modules.  The  ModelMerge 
module  -  a  deterministic  merge  module,  acts  together  with  the  ModelSelect  module  to  preserve 
FIFO  (first-in- first-out)  ordering  of  tokens  through  the  subgraph.  The  two  modules  preserve 
the  FIFO  ordering  of  multiple  tokens  entering  two  different  paths,  the  oil  model  path  and  the 
sand  model  path.  The  ModelSelect  module  informs  the  ModelMerge  module  of  the  order  in 
which  it  injects  tokens  into  the  subgraph.  The  ModelMerge  module  merges  the  outgoing  tokens 
in  the  order  specified  by  the  ModelSelect  module. 

Stream  Machine  code  for  the  ModelSelect  and  the  ModelMerge  modules  (Figure  3.2.3) 
illustrates  this  behavior.  The  code  shows  that  the  choice  of  the  second  input  stream  to  the 
ModelMerge  module  is  dependent  on  the  value  along  the  first  input  stream,  the  select  stream. 
It  illustrates  that,  while  other  modules  consume  a  static  set  of  input  tokens,  a  deterministic 
merge  module  selects  the  remainder  of  its  input  set  based  on  the  value  of  the  token  along  its 
select  stream. 

In  addition,  both  the  ModelMorgo  module  and  the  MonitorMerg®  module  forward  adl  output 
to  the  Process  module  for  further  processing.  The  Process  module  sends  data  to  the  Display 
module  for  immediate  display  and  to  the  Record  module  for  long  term  storage. 

We  constreiin  both  types  of  feedback  in  SAMPLE  -  tool  recovery  feedback  and  pzirameter 
adjusting  feedback.  Here,  we  offer  an  informal  description  of  these  constraints.  A  formal 
specification  will  follow  in  Figures  5.5  «ind  5.6. 

First,  we  constriiin  tool  recovery  feedback  -  the  time  it  teikes  the  monitoring  segment  of 
SAMPLE  to  generate  a  recovery  signal.  This  constraint  is  conditional  on  SAMPLE’S  detection 
of  abnormal  conditions.  Under  normal  tool  conditions,  a  recovery  signal  wiU,  of  course,  not  be 
generated.  Since  each  of  the  two  performance  monitoring  modules  receives  only  every  other 
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NodelS6l«ct: 
data  =  . . . ; 
if  (data  ==  . . . ) 

vrito(#8,0ilNod«l) ; 

7rite(*4,data) ; 
els« 

write (#8, 'SandModel) ; 
write(#9,data) ; 

OilHodelMerger: 
if  (read(#8)  ==  ’OilHodel) 

write(#16,  read(#6));  '4merge  from  oil  model 

else 

write(#16,  read(#10));  '/.merge  from  sand  model 

Figure  3.16:  Sample  Code  for  the  HodelSelect  and  ModelMerge  Modules. 

data,  they  will  both  detect  abnormal  conditions  after  two  cycles.  As  a  result,  we  constrain  the 
time  it  takes  to  generate  a  recovery  signal  to  be  no  more  than  two  cycles.  Say.  for  instzmce, 
that  the  tool’s  sampling  cycle  tnl'cc  150  lime  units.  Then  the  time  it  takes  two  successive 
tokens  cdong  stream  2  to  propagate  through  the  performance  monitoring  segment  of  SAMPLE 
(Figure  3.13)  and  generate  a  recovery  signal  along  stream  1  must  be  less  than  300  time  units. 

Second,  we  constrain  parameter  adjusting  feedback  -  the  time  it  takes  the  parameter  adjust¬ 
ing  segment  of  SAMPLE  to  adjust  tool’s  parameters.  This  time  varies  depending  on  detected 
formation.  An  oil  rich  formation  requires  different  adjustments  then  a  sandy  formation.  In 
either  case,  we  constraun  SAMPLE  to  generate  adjustment  pairameters  before  the  tool’s  next 
cycle.  We  assume  the  tccl’s  sampling  cycle  to  be,  agaiin,  150  time  units.  Then  the  time  before 
one  initial  token  along  stream  2  propagates  through  the  oil  or  the  sand  model  (Figure  3.15.) 
and  produces  one  token  along  stream  1  must  be  no  more  than  150  time  units. 

3.2.4  Program  and  Constraint  Characteristics 

We  have  looked  at  three  different  programs  in  this  section:  the  SAT,  the  SLT-L,  and  SAMPLE, 
j’rom  these,  we  cam  draw  several  conclusions  about  the  prograuns  in  our  domaun.  First,  aill 
three  programs  contained  cyclic  paths.  These  paths  were  used  to  provide  feedback.  Second,  all 
three  programs  received  periodic  data  from  a  tool.  Finally,  the  behavior  and  timing  of  all  three 
programs  depended  heavily  on  input  data. 
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Yet  another  characteristic  of  our  programs  was  balanced  flow  of  data.  Because  of  limited 
buffer  sizes,  tokens  could  not  accumulate  indefinitely  along  ainy  one  arc.  Moreover,  because  of 
our  FIFO  model,  tokens  covdd  not  be  discarded  upon  buffer  overflow.  As  a  result,  the  airrived 
of  tokens  along  the  input  arcs  of  a  module  had  to  be  balanced  and  consumed  steadily.  The 
MonitorMerge  module  of  Figure  3.12  illustrated.  The  module  awadted  one  token  along  stream 
12  for  every  one  token  adong  stream  14. 

For  each  of  the  three  programs  we  have  discussed,  we  have  described  real-time  constraints 
which  bind  the  program.  Read-time  constradnts  in  all  three  programs  also  shared  severad  ma¬ 
jor  characteristics.  First,  constraints  were  absolute,  numeric  limits,  as  opposed  to  relative, 
precedence  limits.  They  were  often  dictated  by  feedback  control  rates.  In  general,  constraints 
specified  propagation  delay  from  an  initiad  point  to  a  final  point  through  many  possible  com¬ 
putation  paths. 

In  addition,  the  constradnts  we  saw  rainged  from  hard  to  very  soft.  A  signal  to  retrieve  a 
madfmctioned  multi-mdlion  doUair  tool  was  am  example  of  a  hard  signal.  Any  chance  of  missing 
the  constraint  limit  was  a  clear  failure.  In  contrast,  a  high  rate  signal  to  adjust  tool  speed  was 
am  example  of  a  soft  signad.  An  unlikely,  ramdom  chance  of  missing  the  constraint  limit  was 
acceptable. 

.41so,  constraints  could  be  conditional  on  branching  decisions  within  the  computation.  For 
instamce,  in  our  SAT  example,  the  user  constrained  a  criticad  path  of  unguaramteed  existence, 
the  path  from  the  Pressure  stream  to  the  PotrerOff  stream.  Given  a  token  on  the  Pressure 
stream,  a  corresponding  token  on  the  PoserOf  f  stream  is  conditional  on  the  PowerOf  f  branch 
of  the  Merge  module. 

3.2.5  Sample  Machine 

Having  looked  at  several  programas,  we  next  look  at  a  sample  machine.  Figure  3.17  shows  the 
diagram  of  a  sample  machine.  Tables  3.2  amd  3.1  give  the  machine’s  heterogeneous  chamnel  amd 
processor  parameters.  This  machine  is  similar  to  the  wireUne  acquisition  machine  of  Figure  2.2. 
It,  too,  hais 

•  two  workstations.  Workstation!  and  Workstation2,  (of  uneven  capacity) 

•  an  uphole  tool  processor,  the  Acquisition  processor,  connected  to  one  of  the  two  work¬ 
stations,  and 
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•  a  downhole  processor,  the  DosnHole  processor,  connected  to  the  uphole  processor. 

This  sample  machine  is  typiczd  in  its  lack  of  homogeneity.  It  is  composed  of  diverse  pro¬ 
cessors  with  varying  h£urdware  (speed)  and  system  level  pairameters  (multitasking,  interprocess 
communication,  scheduling  method  . . . ).  Channels  cormecting  individual  processors  are  equally 
diverse.  Channel  hardware  (speed,  latency)  and  system  level  parameters  (broadcast,  one  way 
communication,  . . .  )  vary. 


Figure  3.17;  Sample  Machine. 


Processor  Parameters 

# 

Neime 

Available 

Capacity 

1 

DownHole 

100% 

2 

Acquisition 

100% 

3 

Workstation! 

80% 

4 

Workstation2 

100% 

Table  3.1:  Parameters  for  Sample  Machine  Processors. 


3.2.6  Sample  Allocation 

We  conclude  our  extimples  with  a  sample  allocation  of  our  saunple  prograun  onto  our  sample 
machine.  Figure  3.18  illustrates.  It  shows  the  allocation  of  individual  program  modules  to 
processors.  Program’s  streams  have  been  allocated  so  as  to  connect  each  producer  module  with 
aU  of  its  consumer  modules.  As  we  see  from  the  figure,  the  number  of  processes  and  streams 
greatly  exceeds  the  ntimber  of  processors  and  channels,  lcc»dh.g  to  resource  contention. 

Any  allocation  of  the  sample  program  onto  the  sample  machine  is  constrained  by  three 
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Channel  Parameters 

# 

Name 

Packet  Propagate 
Latency 

Direction 

From  To 

l“ 

SignadUp 

4 

1-2 

2 

SignalDown 

4 

2-1 

3 

SharedMemoryUp 

0 

2-3 

4 

ShaxedMemoryDown 

0 

3-2 

5 

TruckNetwork 

10 

5,6-5,6 

Table  3.2:  Parameters  for  Scimple  Machine  Chcinnels. 


dedicated  resource  constraints.  First,  the  Tool  module  must  be  edlocated  to  the  Downhole  pro¬ 
cessor.  (Conversely,  no  module  other  than  the  Tool  module  may  be  edlocated  to  the  Downhole 
processor.)  Second,  the  Acquisition  mod\Lle  must  be  jdlocated  to  the  Acquisition  processor. 
And  third,  the  Display  module  must  be  allocated  onto  the  Workstation2  processor. 

It  is  easy  to  see  that  our  saunple  allocation  satisfies  dedicated  resource  constraints.  The  Tool 
and  the  Acquisition  modules  are  the  sole  occupants  of  their  dedicated  resources,  the  Downhole 
and  the  Acquisition  processors.  And  the  Display  module  has  been  correctly  allocated  to 
Workstation2.  The  allocation  also  satisfies  topology  constraints.  All  communicating  modules 
cire  able  to  communicate  via  connecting  channels  and  processors.  To  satisfy  machine  capacity 
constraints,  we  need  to  determine  the  maximum  load  on  each  processor  and  chaniitl.  Tliis 
information  will  easily  follow  from  our  verification  of  real-time  constraints  in  chapter  6.  In 
the  remainder  of  this  thesis,  we  will  consider  whether  this  zdlocation  satisfies  sample  prograim’s 
real-time  constraints. 


3.3  Summary 

Before  attempting  a  specification  of  timing  costs  and  constramts,  we  must  gziin  a  practiced 
understcinding  of  our  domain.  This  chapter  attempted  just  that.  In  doing  so,  it  hinted  at 
several  problematic  aireas. 

First,  this  chapter  illustrated  the  degree  to  which  program’s  timing  depends  on  input  values. 
In  the  SAMPLE  program,  for  example,  the  time  to  update  tool’s  parameters  depended  on  the 
formation  surrounding  the  tool.  Different  calculations  were  called  for  in  an  oily  or  sandy 
formation.  Even  the  existence  of  timing  constraints  weis  conditional  on  input.  SAMPLE’S 
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Workstation  2 


Figure  3.18:  Sample  Allocation  of  ProgTcim  onto  Machine. 

recovery  signal  would  not  be  generated  without  am  abnormad  status  data  from  the  tool. 

In  addition,  adlocation  affected  program’s  timing.  First,  the  speed  of  program’s  modules 
and  streams  depended  on  their  assigned  oro<'e««nr«  ph.'^  rlTon-"..!.?  Some  modules,  such  as  the 
Tool  module  in  SAMPLE,  would  not  run  at  aill  imder  some  assignments.  Thankfully,  we  do 
not  attempt  to  adlocate  prograim’s  resources  in  this  work.  However,  our  timing  verifications  wiU 
have  to  be  allocation  dependent. 

More  seriously,  allocation  onto  limited  number  of  resources  indicated  timing  costs  due  to 
contention.  In  our  saunple  adlocation,  for  instance,  eight  different  modules  competed  for  one 
processor.  With  severad  modules  activated  concurrently,  the  contention  time  could  easily  exceed 
the  execution  time  of  a  module. 
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Chapter  4 

Timing  Specification 


Having  described  onr  domain,  we  proceed  to  address  the  first  gofd  of  this  project  as  outlined 
in  Chapter  2  (page  15)  -  a  timing  specification  of  a  feedback  process.  Our  goal  is  to  to  specify 
enough  timing  information  in  order  to  verify  real-time  constraints. 

.A.t  present,  our  description  of  a  feedback  process  consists  of  program's  instructions  and 
its  allocation.  Take  our  SAMPLE  program.  We  are  given  a  number  of  modules  and  streams 
(Figure  3.12),  together  with  the  source  code  of  each  module  aind  with  SAMPLE'S  processor  cind 
channel  mappings  (Figure  3.18). 

We  are  asked  to  verify  whether  a  constraint  is  met.  Take  the  simplest  constraint  through 
a  single  module  such  as  SAMPLE’S  Honitorl  module.  Figure  3.14  showed  the  source  code  for 
this  module.  Say  we  constrain  the  time  from  the  arrival  of  a  token  along  stresim  11  to  the 
creation  of  one  token  along  stream  12  to  be  less  than  z  time  units.  How  do  we  verify  this 
constraint? 

Excluding  all  other  costs,  the  simple  time  to  execute  Honitorl’s  instructions  up  to  and 
including  the  generation  of  a  token  along  stream  12  is  not  constant.  The  time  varies  with  the 
input  value  read  on  stream  11.  But  our  imposed  constrsiint  must  be  met  for  einy  input  vadue. 

Fortunately,  we  can  derive  an  upper  boimd.  We  can  derive  the  maximum  possible  time  to 
execute  instructions  up  to  and  including  the  generation  of  a  token  along  stream  12.  It  is  the 
time  to  execute  Monitorl’s  most  time  demanding  instruction  trace  on  Workstation!  up  to 
and  including  a  “write(#12,. . .  )”  instruction.  This  is  the  instruction  trace  resulting  from  100 
iterations  of  Monitorl’s  while  loop. 

In  order  to  verify  the  feasibility  of  generating  one  token  along  stream  12  within  z  time  units 
of  an  arrived  token  along  stream  11,  we  have  specified  the  longest  execution  time  separating  the 
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two  events.  The  specification  amounted  to  Listing  the  maximum  time  for  the  Monitorl  module 
to  generate  a  token.  In  order  to  verify  the  feasibility  of  a  constrcunt  through  multiple  modules, 
we  will  need  to  specify  execution  times,  independent  of  data  vedues,  along  all  intermediate 
modules  and  streams. 

We  wiU  not  tackle  timing  costs  caused  by  contention  in  this  chapter.  Since  other  timing 
costs  are  unaffected  by  contention,  we  wdl  postpone  discussion  of  contention  until  the  following 
chapter.  Our  aim,  by  the  end  of  this  chapter,  will  be  to  specify  enough  information  in  order  to 
verify  real-time  constraints  in  a  contention  free  program. 

We  approach  our  specification  design  with  several  goals. 

1.  Data  Independence:  Most  importantly,  we  wish  to  avoid  data  dependent  specification. 
To  draw  on  data  values  of  tokens  would  be  to  return  to  the  code-level  description  of  each 
module  and  to  verification  through  repeated  program  execution.  Instead,  our  goal  is  to 
statically  isolate  ail  possible  time  events  and  associated  timing  costs. 

2.  Separation  of  Program  and  Machine;  We  wish  to  preserve  the  Stream  Machine's 
clean  separation  of  program  and  machine  description.  Program  behavior  specification 
should  draw  purely  on  a  program;  the  associated  timing  specification  should  draw  on  an 
allocated  program. 

3.  Modularity:  We  wish  to  preserve  the  modularity  of  the  Stream  Machine  description. 
Our  program  specification  should  specify  behavior  and  associated  tuning  at  component 
level. 

Our  first  goal  is  to  describe  the  behavior  of  a  feedback  process.  We  would  like  to  Isolate  all 
actions  which  take  time.  In  case  of  a  stream,  the  action  is  clear:  it  is  the  propagation  of  a  token 
along  that  sticam.  In  case  of  a  module,  time  consuming  actions  become  less  obvious.  .\t  each 
invocation,  a  module  may  output  tokens  cilong  different  streams  at  different  times.  Its  output 
may  depend  on  its  input  Vcilues  as  well  as  on  its  periodicity.  In  case  of  the  deterministic  merge 
module,  even  the  invocation  time  is  conditional  on  which  streams  the  selector  stream  selects 
for  input.  Somehow,  we  must  abstract  module’s  behavior  to  capture  all  possible  timing  costs. 
Having  described  all  actions  which  take  time,  we  will  then  move  on  to  assign  timmg  costs  to 
each  action  and,  finally,  to  simulate  timing  and  behavior  of  the  entire  program. 
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4.1  Abstracting  Behavior  of  a  Module 

In  each  module’s  invocation,  severed  actions  characterize  the  advamcement  of  time.  Take  the 
general  module  of  Figure  4.1.  The  module  is  invoked  at  the  moment  it  accumulates  adl  awedted 
tokens  edong  streams  si  though  Sm-  It  consumes  its  input  tokens  and  executes  for  some  time. 
At  certain  times  past  its  invocation,  the  module  outputs  tokens  edong  streams  Sj  through  s'^. 


si 
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sm 


si’ 

s2’ 

sn’ 


Figure  4.1;  Sample  Module. 


Simple  Modules 

We  start  our  exploration  of  behavior  with  the  simplest  possible  module.  This  module  awaits 
one  token  along  one  input  stream  and  executes  outputting  one  token  along  one  output  stream. 
sample’s  Monitorl  module  is  an  example.  Monitorl  consumes  one  token  along  stream  11 
and  then  executes  outputting  one  token  along  stream  12.  Referring  to  the  general  module  of 
Figure  4.1,  our  description  simply  lists  the  one  input  md  the  one  output  stream,  indicating 
execution  by  am  arrow 

Si  -  s'l.  (4.1) 


In  case  of  the  Monitorl  module: 


■*11  ^  -^iz- 

.4  simple  extension  of  our  description  allows  for  one  token  along  each  of  multiple  input 
streams  and  each  of  multiple  output  streams.  An  example  of  this  timing  behavior  is  SAMPLE’S 
0il2  module.  0il2  consumes  one  token  along  stream  5  and  then  executes  outputting  one  token 
along  stream  6  and  one  token  along  stream  7.  Our  extended  description  simply  list  aU  input 
streams  and  cdl  output  streams,  again  indicating  execution  by  an  arrow 

SlASjA...3m  — *  3\A3',A...s'^.  (4.2) 
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In  case  of  the  0il2  module: 


3s  — *  SqASt- 


Finally,  a  module  may  await  mtiltiple  tokens  along  any  one  input  stream  cind  produce 
multiple  tokens  along  any  one  output  stream.  An  example  is  SAMPLE’S  Sand  module  which 
consumes  two  tokens  along  stream  9.  In  our  description,  we  include  multiple  tokens  along  a 
stream  by  adding  an  optionad  coefficient,  c,  in  front  of  that  stream: 

C1S1AC232A  .  c'jSiACjJjA  .  .  (4.3) 

In  case  of  the  Sand  module: 


2S9  — *  SiQ. 


Selector  Modules 

The  first  difficulty  arises  with  data  dependent  modules.  These  modules  behave  differently 
depending  on  values  of  input  tokens.  They  select  their  behavior  based  on  values.  Take  the 
MonitorMarga  module  which  consumes  one  token  along  stream  12  and  another  one  along  stream 
14.  Depending  on  the  values  of  these  tokens,  MonitorHerga  does  or  does  not  generate  a  token 
along  stream  17.  As  our  ultimate  goal  is  a  data  independent  verification,  we  cannot  incorporate 
token’s  values  into  our  description.  Instead,  we  describe  £ill  possible  behaviors,  making  no  choice 
among  them: 


CiSi  AC2S2A  . 

^  ^1,1  ^^1,2 ^2'^  ' 

J  *  A  f  f  A 

C2  2^2^  ’ 

In  case  of  the  MonitorMarga  module: 


(4.4) 


S12AS14  — ►  5i7 


We  wUl  refer  to  the  description  of  Equation  4.4  as  a  behavior  statement.  A  behavior 
statement  states  how  a  module  will  behave  for  a  given  input  set  of  tokens. 
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Merge  Modules 


Yet  another  variation  on  Equation  4.2  captures  the  behavior  of  merge  modules.  In  its  simplest 
form,  merge  modules  merge  the  values  cdong  two  input  streams  onto  a  single  output  stream. 
SAMPLE’S  Process  module  is  am  example.  Process  awaits  one  token  along  stre2un  16  or  one 
token  along  stream  17.  Whenever  a  token  along  either  stream  arrives,  Process  consumes  the 
token  and  executes,  generating  one  token  along  stream  15.  The  behavior  of  the  Process  module 
can  be  described  by  two  statements: 


•*16  — *  ■*15 

•*17  — ^  •Sis- 


In  general,  the  behavior  of  a  merge  module 
share  the  same  output  sets: 

^l,l^*l^^l,2*2'*^  *  •  *  ^l,m*m 


C2,1*iAC2,2-S2A  .  .  .  C2  ,m^m 


can  be  described  by  multiple  statements  which 

‘^1,1'*1^^1,2'*2A  •  •  •  c'l 

— ►  C2.1'’i^^2,2'*2'^  •  •  • 

<^i,l^i'''^1.2'*2'^  •  •  •  ^l.n'^n 
— ►  C2,1'*iAC2,2*2  A  •  •  •  C2,n^n 


(4.5) 


Deterministic  Merge  Modules 

We  next  consider  several  ways  to  model  the  behavior  of  a  deterministic  merge  module.  We  have 
already  seen  the  deterministic  merge  module’s  role  in  preserving  FIFO  ordering  in  Section  3.2.3. 
In  the  model  subgraph  in  Figure  3.15,  the  selector  module  ModelSelect  together  with  the 
deterministic  merge  module  NodelMsrge  mciintained  the  FIFO  ordering  of  tokens  entering  and 
exiting  the  subgraph.  To  correctly  model  the  behavior  of  the  saimple  program,  we  too  must 
preserve  this  ordering  in  our  specification  of  modules’  behavior. 

We  start  our  specification  of  the  deterministic  merge  module  ModelMerge  from  our  specifi¬ 
cation  of  a  simple  merge  module  (Equation  4.5): 


ssAsa  •*16 
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•sioA^s  -*  -sie* 


Here,  an  input  token  on  stream  8  matches  either  an  input  token  on  stream  6  or  ein  input 
token  on  stream  10,  depending  on  which  of  the  two  arrives  first.  The  select/merge  pair’s  FIFO 
synchronization  is  simply  ignored. 


Speculative  A  slight  improvement  lets  us  specify  every  possible  synchronization  along  our 
select/merge  pair.  Since  we  do  not  know  which  set  of  input  tokens  a  selector  token  will  name, 
we  specify  aU  possibilities.  We  separate  different  possibilities  with  a 


statementi 

I  stateTnent2 


(4.6) 


Within  this  notation,  specification  of  the  ModelNerge  module  becomes: 

The  arrival  of  one  token  along  stream  6  and  one  token  tdong  stream  8  does  or  does  not  fire  am 
invocation  of  the  module  depending  on  which  of  the  possible  statements  we  consider. 

An  obvious  disadvantage  of  this  approach  is  that  the  behavior  of  all  but  one  statement  is 
unrealistic.  Take  the  case  where  the  ModelSelect  module  has  generated  one  token  each  along 
streams  4  and  8.  Choosing  ModelMarge  module’s  first  statement,  seAss— correctly  portrays 
the  module’s  behavior  and  preserves  the  select /merge  pair’s  FIFO  synchronization.  However, 
choosing  Mod«lM«rge  module’s  second  statement,  SioAsg— leads  to  infeasible  behavior.  The 
choice  leaves  two  unconsumed  tokens,  one  along  stream  6  and  one  along  stream  8,  forever. 

Acknowledged  We  cam  assert  FIFO  ordering  through  an  explicit  addition  of  acknowledgment 
streaims  to  select/merge  pairs.  Figure  4.2  illustrates  on  our  oil  model  example.  With  am  added 
acknowledgment  streaim,  streaun  18,  the  specification  of  ModelSelect’s  actions  becomes: 


sjAsis  — ►  S4AJ8 

-*  239AJ8 
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Figure  4.2:  The  Model  Segment  of  SAMPLE  with  an  Explicit  Acknowledgment  Stream. 
Specification  of  Mod«lM«rg«’s  actions  becomes: 

•SloAsg  "*■  >*16ASig 

This  solution  is  not  optimal.  It  limits  parallelism  and  lowers  execution  speed  by  sequenticd- 
izing  entry  into  each  select /merge  pair. 

However,  in  feedback  control  programs,  such  as  SLT-L  (Section  3.2.2),  select /merge  pairs 
are  commonly  used  for  generality  rather  thcin  synchronization.  In  fact,  this  is  the  case  in  our 
sample  program.  Here  the  tool  cycle  time  exceeds  the  propagation  time  along  either  brzinch  of 
the  model  segment^.  As  a  res’ult,  FIFO  ordering  through  this  select/merge  pair  is  guarauiteed 
and  no  acknowledgment  is  necessary.  Because  within  our  application  domain  explicit  FIFO 
enforcement  is  often  unnecessary,  we  leave  implementation  of  the  alternative  tagged  approach 
below  for  further  work. 

Tagged  A  more  satisfying  approach  is  the  explicit  treatment  of  select /merge  pairs.  Here  we 
capture  the  alignment  of  the  select  module’s  and  the  deterministic  merge  module’s  actions. 
On  each  invocation  of  the  select  modvde,  we  tag  the  generated  selector  stream  token  with  its 
output  set  selection.  The  corresponding  merge  module  checks  the  tag  of  its  input  token  along 
the  selector  stream  in  order  to  select  the  remainder  of  its  input  set. 

We  describe  the  select  module  as: 

Cj  AC232 A  .  .  .  C,T»^m  *  ■*! ACj  2"*2A  •  •  >  ~ 

‘It  must  in  order  for  feedback  to  affect  the  next  measiuement  -  a  constraint  imposed  in  section  3.2.3 


43 


— >  •SiAC2_2'S2^  •  •  •  C2,n^n»  •*!  =  Tag2 

...  (4.7) 

Here,  tokens  cilong  selector  stream,  s'^,  are  assigned  a  tag  designating  the  select  module’s  choice. 
Correspondingly,  the  merge  module  selects  its  input  set  according  to  the  supplied  tag: 

If  Si  ==  Tagi,  SiAc2S2A...c„iS„,  <:i.i^i^‘^i.2^2A...ci,„s^ 

— ^  *  '  *  ^2»n^n 

If3i==Tag2,  ...  —  ...  (4.8) 

Like  the  speculative  approach,  this  solution  does  not  modify  the  original  program.  In 
addition,  it  is  always  correct,  preserving  the  intended  FIFO  synchroniaation.  Table  4.2  shows 
the  tagged  behavior  specification  of  our  ModelSelect  emd  HodelHerge  pair. 

However,  the  introduction  of  tags  into  otii  description  is  worrisome.  At  first  glance,  it 
seems  that  we  have  violated  our  main  goal  -  a  data  independent  specification.  Tokens  along  the 
selector  stream  clearly  carry  values  from  the  select  module  to  the  merge  module.  The  timing 
behavior  of  the  merge  module  depends  on  the  tag  vadue  edong  its  selector  stre£tm.  Are  we  back 
to  verification  through  repeated  execution  for  each  possible  input  value?  Not  qmte.  Unlike 
data  values,  tags  do  not  directly  affect  evaluation,  instead,  they  align.  They  align  actions  of 
the  merge  module  with  those  of  the  select  module.  Through  a  finite  number  of  choices,  tags 
describe  all  valid  £dignments  of  those  two  modules’  actions. 

Deterministic  Merge  Modules  Summary  We  have  seen  two  satisfactory  ways  to  express 
the  behavior  of  deterministic  merge  modules  -  through  the  addition  of  acknowledgment  streams 
and  through  tagging.  Tables  4.1  £ind  4.2  show  SAMPLE  modules’  behavior  specifications  under 
the  two  schemes. 

State  Dependent  Modules 

In  our  assumption,  we  have  restricted  the  Stream  Machine  modules  to  two  states;  each  module 
is  either  reading  its  input  streams  or  executing,  irrespective  of  the  module’s  history.  This 
restriction  simplified  our  specification  at  the  cost  of  lowered  performance  Md  expressiveness. 
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Execution  that  might  have  preceded  otherwise  is  postponed  until  all  input  streams  have  been 
read.  And,  more  importantly,  information  regarding  periodic  behavior  of  a  module  is  lost. 

Periodicity  played  a  role  in  the  timing  of  two  of  oiir  three  illustrative  programs,  .jouccessivc 
cycles  of  the  SAMPLE  program  invoked  one  of  two  monitoring  calculations.  In  the  SLT-L 
program,  successive  cycles  interleaved  among  four  computations  adjusting  the  tool’s  parameters. 

We  illustrate  consequences  of  neglected  periodic  behavior  on  SAMPLE’S  monitor  subpro¬ 
gram  (Figure  3.13).  At  this  point  om  best  approximation  of  the  MonitorSelect  module’s 
behavior  is: 


53  5ii 


•»r3- 


This  specification  states  that  on  each  invocation,  the  MonitorSelect  module  generates  either 
one  token  along  stream  11  or  one  token  along  stream  13.  The  specification  does  not  capture 
the  periodic  interleaving  of  output  to  streams  11  and  13. 

As  a  result,  the  subsequent  input  set  specification  of  module  MonitorMerge,  3i2A3i4,  is 
unrealistic.  The  specification  of  the  MonitorSelect  module  does  not  guarantee  a  balanced 
arrival  of  tokens  at  streams  12  and  14.  The  MonitorMerge  module  may  produce  no  output  and 
accumulate  an  overflow  of  tokens  along  one  of  its  two  input  strecuns.  Clearly,  this  is  not  the 
behavior  we  wished  to  specify. 

To  recapture  the  periodic  behavior  of  modules,  we  can  relax  the  “statelessness”  assumption 
and  allow  midtiple  module  states.  By  convention,  we  use  state  1  as  the  initial  state: 

state  x:  statement^ 

next  state:  state  y.  (4.9) 

For  instance,  the  timing  actions  of  the  MonitorSelect  module  become: 

state  1:  33  — »  Sn 

next  state:  state  2 

state  2:  33  — ►  313 

next  state:  state  1 
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It  is  interesting  to  note  that  we  have  not  reverted  to  a  CSP  model.  Our  deterministic  finite 
automata  of  module  specifications  allow  for  periodic  states.  They  do  not  edlow  for  data  depen¬ 
dent  By  attr.chir-g  next  state  to  individual  cutput  sc*:3,  rtiiher  thcui  sets  of  statements,  we 

could  easily  reclciim  a  CSP  model.  However,  none  of  the  sample  progreims  of  Chapter  3  indicate 
a  need  for  this  additional  source  of  nondeterminism  -  a  nondeterministic  finite  automaton. 


SAMPLE  Modules’  Time  Critical  Actions 

Module 

State 

Statement 

Next  State 

Tool 

- 

Sl  — 

- 

Acquisition 

■ 

32  —  53 

516  — 5i 

517  — 5i 

- 

Models  elect 

- 

53'^5i8— +34A38 
— ►239AS8 

“ 

Oill 

• 

54  —  55 

57— 

• 

0il2 

- 

35— >36^37 

- 

Sand 

- 

239— >310 

- 

ModelMerge 

38A38  — 3i6A3i8 
510^38  — 3i6A3i8 

- 

MonitorSelect 

1 

53  —  511 

2 

2 

53  —  513 

1 

Monitorl 

• 

5ll— 512 

- 

Monitor2 

- 

513  — 514 

- 

MonitorMerge 

• 

5i2A514-+3i7 

• 

Process 

- 

518  — 5i5 

5i7  — 515 

- 

Record 

- 

5i5  — 

- 

Display 

- 

515  — 

- 

Table  4.1:  Specification  of  SAMPLE  Modules’  Behavior  Using  Acknowledgment  Streams  for 
Deterministic  Merge  Modules. 


Generalization  of  Merge  Modules 

Finally,  we  Ccin  expand  the  specification  of  merge  modules  to  allow  different  behavior  for  dif¬ 
ferent  input  sets: 


Ci,i  JiACi,2JjA  .  ..Cl 

,m^m 


/ 

n 
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SAMPLE  Modules’  Time  Critical  Actions 

Module 

State 

Statement 

Next  State 

Tool 

- 

- 

Acquisition 

- 

32  — «3 

316— 

317—  3l 

- 

Models  elect 

33— 34A38,  38  =  Tag\ 

— »239A38,  38  =  Tagi 

• 

Oill 

• 

34—35 

37— 

- 

0il2 

- 

35— +36A37 

- 

Scind 

- 

239  —  310 

- 

ModelMerge 

• 

If  38  ==  Taffj,  38A36— 3i6 

If  38  ==  Tagi,  38A3io  — 3i6 

• 

MonitorSelect 

1 

33  — 3ii 

2 

2 

33  —  313 

1 

Monitorl 

- 

3ll  — 312 

- 

Monitor2 

- 

3i3  — 3i4 

- 

MonitorMerge 

• 

3i3A3i4-*3i7 

Process 

*■ 

3i6  — 3i5 

3i7— 3i5 

- 

Record 

- 

3i5  — 

- 

Display 

- 

3i5  — 

- 

Table  4.2:  Specification  of  SAMPLE  Modules’  Behavior  Using  Tagging  for  Deterministic  Merge 
Modules. 


Where 


state  1:  statement  s\ 

next  state:  state  ii. 

state  s:  statements^ 

next  state:  state  i,. 


1  <  i  <  a 


and  where 

statement  =  c\S\Ac2S-iA  . .  .CmSm 


Figure  4.3:  Our  Specification  of  Module’s  Time  Critical  Actions. 


C2,iaiAC2,2'*2A  .  .  . 


‘^2.1.1^! '''‘^2,1,2 ^2-^  •  •  •  ‘^2,1, n^n 
<^2,2,1^1^‘'2,2,2^2^  •  •  •  <^2,2.n'*n 


;  (4.10) 

This  generadized  specification  of  merge  modules  does  more  then  merge  streams  nondetermin- 
istically.  A  useful  analogy  is  a  set  of  gusu’ded  CSP  commands.  Each  command  has  a  different 
test,  its  input  set;  and  potentially  a  different  body,  its  output  set.  Since  they  share  the  same 
modvde,  commands  are  sequentially  ordered  -  no  two  can  execute  concurrently.  Also,  since  they 
share  the  same  module,  commands  C2m  share  variables.  Moreover,  since  they  share  the  same  set 
of  potentiail  output  streams,  commands  can  nondetenninistically  merge  tokens  onto  the  same 
stream. 

Module’s  Abstract  Behavior  Summary 

In  this  section,  we  have  specified  all  actions  within  a  module  invocation  which  take  time. 
Table  4.1  summarizes  our  specification.  We  have  captured  the  time  of  invocation,  by  listing  all 
awaited  input  tokens.  We  have  indicated  execution  time  with  an  arrow  We  have  included 

points  in  time  when  a  modvde  generates  an  output  token  by  listing  all  output  tokens. 
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We  have  extended  our  original  specification  of  one  input  set,  and  a  single  evaluation  thread 
(an  cirrow  and  an  output  set)  to  include; 

1.  multiple  ou'.put  sets  due  to  data  dependent  modules, 

2.  multiple  input  sets  due  to  merge  modules, 

3.  explicit  acknowledgment  streams  due  to  deterministic  merge  modules, 

4.  state  dependent  specifications  due  to  periodic  modules,  ctnd  finally 

5.  multiple  independent  statements  due  to  gueirded  commands. 

Table  4.1  illustrates  our  final  specification  of  SAMPLE  modules’  abstract  behavior  (Figure  3.12). 

Of  these  extensions,  the  most  drastic  one  was  that  of  mtilt’ple  output  sets.  In  order  to 
achieve  data  independent  specification,  we  have  replaced  data  dependent  computation  with 
a  nondeiermiristic  selection  of  data  independent  computation.  At  a  module  level,  the  intro¬ 
duced  nondeterminicity  was  sufficient  to  model  all  responses  to  an  input  set.  However,  at  the 
inter-module  level,  some  combinations  of  modules’  responses  may  be  unrealistic.  Consider  two 
modules  whose  actions  are  aligned.  Depending  on  program’s  input  va..  'S,  the  two  modules 
either  both  act  one  way  or  another.  A  nondeterministic  specification  of  module’s  actions  will 
not  express  the  alignment  of  their  actions.  We  leave  the  problem  of  inter-module  alignment  for 
future  work^. 


4.2  Module’s  Timing  Specification 

In  order  to  complete  our  timing  specification  of  a  feedback  process,  we  must  extend  module's 
behavior  with  timing  specification.  We  must  assign  a  timing  cost  to  each  action: 

1.  to  the  time  when  a  module  is  invoked, 

2.  to  the  time  during  which  a  module  executes,  and 

3.  to  the  time  when  a  module  generates  a  token. 

Three  issues  complicate  description  of  timing  costs: 

^The  reader  may  have  noticed  that  tags  used  to  align  actions  of  a  select  module  with  those  of  deterministic 
merge  module  could  be  used  to  explicitly  align  actions  of  any  two  modules. 


49 


1.  timing  costs  due  to  contention, 

2.  data  dependent  tinning  costs,  and 

3.  adlocation  dependent  timing  costs. 

The  first  obstacle  are  costs  due  to  contention.  We  cannot  specify  how  long  it  will  take  for  tin 
invoked  module  to  acquire  a  processor;  how  many  times  during  its  invocation  a  module  will  be 
preempted;  or  how  many  arriving  tokens  will  interrupt  its  execution.  The  second  obstacle  are 
data  dependent  costs.  The  duration  of  module’s  execution  and,  relatedly,  the  time  at  which  it 
outputs  a  token,  may  depend  on  the  values  of  input  tokens.  And  finally,  aside  from  contention 
and  data  dependence,  mod’ile’s  execution  cdso  depends  on  its  allocation.  As  we  have  discussed 
in  Section  3.1.3,  the  time  to  execute  module’s  high  level  instructions  varies  non-linearly  with 
the  assigned  processor. 

In  assigning  timing  costs,  we  will  postpone  consideration  of  contention  and  related  runtime 
costs  untU  the  next  chapter.  We  will,  however,  have  to  somehow  abstract  away  data  dependence 
and  ttike  into  accoimt  program’s  cdlocation. 

4.2.1  Simple  Timing 

As  before,  we  start  our  timing  cost  assignment  with  the  simplest  module.  This  module  awaits 
one  token  cdong  one  input  stream  and  executes  outputting  one  token  along  one  output  stream. 
sample’s  Monitor2  module  allocated  to  the  Workstation2  processor  is  an  example.  Monitor2 
is  invoked  when  one  token  arrives  along  stream  13.  Ignoring  all  contention  costs,  Mc.nitor2  then 
executes  for  exactly  30  time  units.  This  is  the  time  it  takes  to  execute  Honitor2’s  instructions 
on  Work6tation2.  In  case  of  Honitor2,  the  trace  of  instructions  to  execute  is  constant;  it  is 
independent  of  any  data  values  <ilong  stre£im  13  or  internal  to  Monitor2.  Ignoring  contention 
costs  again,  Monitor2  generates  one  token  along  stream  14  exactly  10  time  units  past  invocation. 
It  then  continues  to  execute  for  the  remaining  20  time  \mits,  updating  its  internal  state.  One 
way  to  incorporate  this  information  into  our  specification  of  l!onitor2’s  actions  is  as  follows: 

^13  — '  ^n[10]. 

Here,  we  have  taken  the  time  of  invocation  as  our  point  of  reference.  We  have  specified 
Monitor2’s  execution  latency  above  its  execution  arrow.  And  we  have  indicated  the  time 
from  Monitor2’s  invocation  to  generation  of  one  token  rdong  stream  14,  next  to  stream  14. 
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In  general  terms,  we  have  expanded  specification  of  the  simplest  module  from; 


-  i'l,  (4.11) 

to: 

•Si  -Sillj,  (4.12) 

where  L  is  the  time  from  invocation  to  completion,  and  I  is  the  time  from  invocation  to  gener¬ 
ation  of  one  token  along  stream  s'j. 

4.2.2  Data  Dependent  Timing 

4.12  does  not  describe  modules  with  data  dependent  timing.  Take  SAMPLE’S  Monitorl  module 
allocated  to  the  Workstationi  processor.  Much  like  Monitor2,  Monitorl  awaits  one  token 
along  stream  11  and  executes  outputting  one  token  along  stream  12.  However,  Monitorl’s 
trace  of  instructions  vziries  from  invocation  to  invocation.  The  instructions  to  execute  depend 
on  the  data  value  along  input  stream  12.  The  time  to  execute  them  varies  from  50  to  130  time 
units.  Correspondingly,  the  time  to  generate  one  output  token  along  stream  12  varies  from  40 
to  90  time  units. 

Since  our  goal  is  a  data  independent  timing  specification,  we  cannot  specify  the  relation 
between  data  values  and  timing.  Instead,  we  incorporate  Honitorl’s  data  dependent  timing 
into  4.12  by  replacing  exact  latencies  with  ranges  of  latencies.  In  case  of  Monitorl: 

•*11  — "  •»i2l40  -  90]. 

In  general  terms: 

Si  5i[r|,  (4.13) 

where  R  is  the  time  range  from  invocation  to  completion,  and  r  is  the  time  range  from  invocation 
to  generation  of  one  token  cilong  stream  s'j. 

4.2.3  General  Timing 

-A.  minor  expansion  lets  us  specify  multiple  ranges  for  multiple  tokens  edong  each  output  stream. 
Take  SAMPLE’S  ModelSelect  module.  ModalSelect  may  generate  two  tokens  along  stream  9: 

— »  2S9ASS 
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The  first  token  along  stream  9  will  be  generated  5  to  12  time  units  past  invocation,  the  following 
tnken  along  stream  9  will  be  generated  10  to  15  iime  umts  past  invocation: 

•S3''^'Sl8  — "  -54110  -  15]AS8'10  -  15] 

—  2s9t5  -  12, 10  -  ISlAs^TO  -  15] 

We  simply  list  time  ranges  from  module  invocation  to  token  generation  for  the  two  successive 
tokens  along  stream  9.  We  guarantee  monotonic  generation  times  for  successive  tokens  along 
a  stream.  That  is,  the  generation  time  of  the  second  token  along  stream  9  is  guarcinteed  to 
exceed  the  generation  time  of  the  first  token. 


(“ 


si 
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Figtire  4.4:  Seimple  Allocated  Module. 


In  general,  given  a  module  and  its  allocation  (Figure  4.4),  we  expand  a  statement: 

Cl  Si  A  .  .  .  Crn^m  ^ 

'  '  A  f  f 


into: 


CiSiA  .  .  .  Cm^m 


Cl.l-5lifl,l,l,  ri,i,2,  .  .  .  ri,i,c,,,]A  .  .  .  Ci,„s(,[ri,„,i,  ri_n,2,  •  •  • 

^2,1,2,  •  •  •  '’2,1,C3,i]'^  •  •  -  <^2,n5ni''2,n,l,  ''2,n,2i  •  ■  •  ^2.n.C2.n] 


-  (4.14) 

We  indicate  the  rainge  of  latencies  from  module  invocation  to  completion  by  associating  a 
range  with  the  ith  execution  arrow.  We  expand  each  Ci^j  coefficient  cdong  an  output  stream 
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state  1:  statementsx 

next  state:  state  ii- 

state  s:  statements, 

next  state:  state  i,. 

Where 

1  <  i,j  < 

and  where 
statement 

—  Ci3iA.,.Cyn'^m  ^ 

—  t 

Figure  4.5:  Our  Final  Timing  Specification. 

s'j  into  an  eirray  of  Cj,j  latency  ranges  along  stream  s'^.  The  nth  latency  range,  specifies  the 
rcinge  of  latencies  from  module  invocation  to  the  generation  of  the  nth  token  edong  the  output 
stream  s' . 

4.2.4  Module’s  Timing  Summary 

In  this  section,  we  have  aissigned  timing  costs  to  module’s  actions.  Ignoring  contention  overhead, 
we  specified  how  long  it  teikes  to  execute  module’s  instructions.  The  specified  time  depended  on 
module’s  allocation.  We  incorporated  data  dependent  execution  by  specifying  a  range  rather 
than  a  constant  time  cost.  Table  4.3  illustrates  om  timing  specification  on  our  sample  program 
of  Figure  3.12. 

The  reader  may  have  foimd  the  derivation  of  a  range,  a  minimum  and  a  maximum  of 
module’s  latencies,  worrisome.  We  cm  obtain  a  contention  free  latency,  by  running  a  module, 
alone,  on  its  allocated  processor.  We  can  run  all  branches  of  each  conditional  test  to  obtjiin  the 
minimum  and  the  maximum  latencies.  But  what  about  loops?  Note  that  in  order  to  have  a 
finite  maximum  latency,  a  module  must  have  a  limit  on  the  number  of  possible  iterations.  Else, 
the  maximum  latency  is  infinity  and  no  constreunts  can  be  met. 


*^1,1  [^1,1,1)  ^1,1,2 » •  •  •  •  •  •  <^l,n^n[’*l,n.l» 

^2,1  [^2,1,1)  ^2.1, 2j  ‘  ‘  ^2,n^nL’*2.n.l?  ^2,n,2»  *  ■  •  ^2,n,c3,n] 
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Table  4.3:  Behavior  and  Timing  Specifications  for  Our  Sample  Modules. 
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4.3  Program’s  Execution  Model 


Having  described  the  behavior  and  timing  of  each  module,  we  Me  ready  to  describe  the  behavior 
and  timing  of  the  entire  program-  Starting  from  some  initicd  state,  we  Me  ready  to  simulate 
the  program’s  abstract  behavior  through  time.  For  now,  our  simulation  will  ignore  resource 
contention  costs.  In  our  illustrations,  we  will  assume  that  each  one  of  SAMPLE’S  modules  has 
been  reassigned  to  its  own  processor  or  each  one  SAMPLE’S  streams  has  been  reassigned  to  its 
own,  fully  pipelined  cheuinel. 

Figure  4.6  illustrates  the  desired  outcome  of  our  simulator.  In  its  initial  state,  at  time 
0,  the  simulator  finds  one  token  along  si  'eam  2  and  one  along  stream  18.  In  Figure  4.6,  we 
watch  SAMPLE  step  through  time.  At  each  point  in  time,  the  simulator  displays  a  snapshot 
of  sample’s  program  graph,  highlights  invoked  modules,  and  display  tokens  along  streams. 
Whenever  the  simulator  encounters  several  possible  behaviors,  as  at  time  19,  it  forks  a  sepMate 
simulation  for  each  possibility. 

In  this  section,  we  wiU  describe  a  simple  simulator  of  abstract  program  behavior.  The 
purpose  of  this  description  is  to  provide  a  simple  execution  model  for  SM  programs.  The 
reader  should  be  awMe  that  no  attempt  has  been  made  at  optimization,  only  at  clMity  and 
simplicity. 

The  simulator  stMts  with  a  static  description  of  the  prograun  and  its  allocation.  It  creates 
runtime  structures  to  maintain  dynamic  state  of  the  simulation.  StMting  from  initial  state,  the 
simulator  then  simulates  successive  events  in  time,  updating  its  dynamic  state  with  each  event. 

4.3.1  Static  Description 

The  simulator  is  initially  presented  with  a  static  description  of  the  program.  This  description 
embodies  aill  the  information  which  we  have  accumulated  about  a  program  md  its  ciUocation. 
For  the  prograun,  the  simulator  maintains  the  program  graph:  the  name  of  every  module  and 
every  stream  and  their  intercoimection  (Section  3.1).  In  addition,  for  each  module,  the  sim¬ 
ulator  maintains  its  abstract  behavior  aind  its  timing  under  the  allocation  (Section  4.1).  For 
each  stream,  the  simulator  maintains  token’s  propagation  latency  along  that  stream  under  the 
allocation.  Since  the  simulation  is  free  of  resource  contention,  the  simulator  need  not  know 
about  the  underlying  machine. 

As  an  example  of  a  static  description,  consider  again  our  allocated  SAMPLE  program. 


55 


Figure  4.6:  Pjirt  of  Feedback  Constraint  Verification. 
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Its  static  description  will  consist  of  the  program  graph  of  Figure  3.12,  together  with  streams’ 
latencies  under  SAMPLE’S  allocation  (Figrire  3.18  auid  Table  3.2),  and  modules’  behavior  and 
timing  imder  SAMPLE’S  adlocation  (Table  4.3). 

4.3.2  Runtime  State 

So  fcir,  we  have  outlined  the  static  structures  which  correspond  to  our  problem  description.  In 
addition  the  verifier  must  maintain  sever.il  runtime  structures  to  simulate  the  passage  of  time 
and  to  accumulate  results. 

Token 

The  most  obvious  runtime  state  is  the  token.  As  the  verification  progresses,  new  tokens  are 
created,  travel  along  streams,  queue  at  destination  modules,  and  eventually  are  consumed. 
Each  of  these  tokens  identifies  its  stream  and  its  destination  module.  In  addition,  each  token 
is  stamped  with  its  creation  time,  the  time  it  was  created  by  the  producer  module,  and  later 
on  by  its  arrival  time,  the  time  at  which  it  arrived  at  the  consumer  module. 

Module 

The  remainder  of  runtime  state  is  associated  with  individual  modules.  To  illustrate,  Figure  4.7 
shows  the  rxmtime  state  cissociated  with  the  ModelMerge  module. 

First,  each  module  must  maintain  input  queue(s)  for  arriving  input  tokens.  As  input  tokens 
arrive  at  modules,  they  must  wait  for  the  remainder  of  module’s  input  set  to  arrive.  Until  then, 
these  tokens  must  remain  queued  somewhere.  Our  simulator  associates  one  token  queue  with 
each  input  stream.  In  Figme  4.7,  the  simulator  associated  one  token  queue  with  input  streams 
6,  8,  and  10  of  the  HodalMarg*  module. 

Second,  at  any  point  in  time,  each  multi-state  module  must  be  awaire  of  its  current  state. 
As  a  new  invocation  propels  the  module  into  its  next  state,  the  simulator  must  update  module’s 
state  to  reflect  this  change.  In  Figure  4.7,  the  NodalNcrg*  module  is  in  state  1  -  its  only  state. 

Finally,  we  must  insure  that  previous  invocation  r\ms  to  completion  before  another  one  is 
fired.  We  insure  this  by  recording  the  active  invocation  of  each  module.  Only  if  there  is  no 
active  invocation,  Ccin  a  new  invocation  fire.  If  another  invocation  is  active,  any  new  invocation 
must  queue  on  ein  invocation  queue. 
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Input  Stream  i6  Queue 


» 


Input  Stream  s8  Queue 
- > 


Input  Stream  slO  Queue 
- > 

Figure  4.7:  A  runtime  state  of  the  No(l«lN*rg*  module. 

4.3.3  Event-Driven  Simulation 

Having  outlined  aJl  static  and  dynamic  structures  manipulated  by  our  simulator,  we  are  ready 
to  examine  the  simulation  process.  The  simulation  process  is  event  driven.  A  centred  event 
queue  maintains  a  time  ordered  listing  of  all  pending  events. 

We  wiU  illustrate  the  simulator’s  steps  on  the  simulation  outlined  in  Figure  4.6.  Figure  4.8 
shows  successive  steps  through  the  event  queue  as  the  verification  progresses.  AH  successive 
event  queues  at  one  point  in  time  are  boxed.  Within  each  box,  successive  event  queues  are 
separated  by  an  eirrow.  For  example,  three  successive  event-queues  correspond  to  time  0.  This 
is  because  three  events  occur  at  time  0. 

Each  event  in  Figure  4.8  is  described  on  one  line  of  text.  So,  for  instance,  the  initial  event 
queue  contains  two  events:  the  “0  create-token  s2”  event  and  the  “0  create-token  sl8”  event. 
The  time  of  each  event  is  written  first,  followed  by  the  type  of  the  event  and  its  body.  For 
instance,  the  very  first  event’s  time  is  0;  its  type  is  create-token;  and  its  body  is  sj. 

Notice  that  in  Figure  4  6,  the  state  of  the  program  at  time  0  reflects  the  state  after  the  last 
event  at  time  0  has  been  handled.  This  is  the  case  up  to  time  19.  Figure  4.8  stops  at  time  19, 
after  two  separate  verifications  have  been  forked. 

The  overall  control  flow  of  the  simulation  is  simple.  Starting  from  some  initial  state,  the 
simulator  loops  indefinitely,  heindling  the  next  event  in  the  time-ordered  event  queue.  At  each 
iteration,  it  dequeues  one  event  from  the  event  queue  and,  bcised  on  the  type  of  that  event, 
dispatches  to  the  appropriate  event  handler. 

We  have  already  seen  one  type  of  an  event,  the  create-token  event,  above.  We  now  look  at 


Active 

Invocation 


Invocation  Queue 
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Time;  0 


Time:  4 


0  create-token  t2 

0  create-toleen  slS 

i 

4  arrive-token  b2  Acquisition 

0  create-token  ilS 

4  arrive-token  82  Acquisition 

X 

- 

0  arrive-token  slS  ModelSelect 

4  arrive-token  i2  Acquisition 

Time;  9  Time;  19 


9  complete-invocation  Acquisition 

19  arrive-token  s3  ModelSelect 

9  create-token  s3 

19  complete-invocation  MonitorSelect 

4- 

19  create-token  sll 

9  create-token  s3 

- 

9  arrive-token  s3  MonitorSelect 

19  arrive-token  e3  ModelSelect 

19  complete-invocation  MonitorSelect 

19  complete-invocation  MonitorSelect 

19  create-token  sll 

19  create-token  sll 

34  create-token  s4 

31  create-token  s9 

34  create-token  sS 

34  create-token  s9 

39  complete- invocation  ModelSelect 

34  create-token  sS 

39  complete-invocation  ModelSelect 

Figure  4.8:  Events  for  Part  of  Feedback  Constreiint  Verification. 
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the  three  diiFerent  types  of  events  in  our  simulator  and  describe  the  handling  of  each  event  type. 
The  two  more  obvious  event  types  are  creation  and  arrival  of  a  token.  Anytime  a  token  is 
created,  we  must  transport  the  token  across  a  stream  to  its  destination  modules.  Anytime  a 
token  eirrives  at  its  destination  module,  we  queue  the  token  and  try  to  fire  the  module.  However, 
we  cannot  fire  a  module  invocation  before  the  previous  invocation  completes.  A  third  event 
type,  invocation  completion,  informs  us  when  a  current  invocation  terminates. 

Token  Creation 

A  first  type  of  ein  event  is  the  create-token  event.  This  event  creates  a  token  for  each  destination 
module  along  a  stream  and  transports  the  newly  created  tokens  to  their  destination  modules. 
In  our  simple  verifier,  we  assume  that  the  token  need  not  contend  for  any  resources  on  its  way 
through  the  stream.  As  a  result,  the  time  to  traverse  the  stream  is  constant  for  each  token.  We 
compute  each  token’s  arrival  time  at  its  destination  module  and  enqueue  an  arrive-token  event 
at  the  newly  computed  arrival  time. 

Taike,  for  instance,  the  very  first  event  in  the  simulation  of  Figure  4.6:  “0  create-token  s2”. 
To  handle  this  event,  the  create-token  event  handler  first  finds  that  the  only  destination  module 
for  a  token  along  stream  2  is  the  Acquisition  module  and  that  the  time  to  traverse  stream 
2  and  reach  the  Acquisition  module  is  4.  The  event  handler  creates  a  token  whose  creation 
time  is  0,  whose  destination  module  is  the  Acquisition  module  and  whose  eirrival  time  is  4 
(i.e.  0  -I-  4).  Finally,  the  event  handler  enqueues  an  arrive-token  event  at  time  4.  This  is  the 
state  of  the  second  event  queue  at  time  0. 

Token  Arrival 

A  second  type  of  an  event  is  the  arrive-token  event.  Once  a  token  traverses  a  stream,  or  arrives, 
it  enqueues  onto  that  stream’s  input  queue.  Its  arrival  triggers  an  attempt  to  fire  its  destination 
module. 

This  is  the  case  at  time  4  when  a  token  along  stream  2  arrives  at  the  Acquisition  module. 
First,  the  token  enqueues  onto  Acquisition  module’s  token  queue  for  stre^lm  2.  Next,  the 
event  handler  checks  whether  Acquisition  module  is  ready  to  fire. 

To  check  whether  a  module  is  ready  to  fire,  we  compare  module’s  specification  in  its  current 
state  against  the  contents  of  input  stream  queues.  We  look  for  a  statement  whose  full  input  set 
is  queued.  In  case  of  generalized  merge  modules,  we  may  find  more  than  one  statement.  This 
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is  because  the  arrival  of  a  single  token  can  complete  more  than  one  input  set.  In  such  case, 
since  our  programming  model  does  not  specify  which  statement  should  fire,  we  fork  a  separate 
simulation  for  each  satisfied  statement. 

To  check  whether  the  Acquisition  module  is  ready  to  fire  at  time  4,  for  instance,  we  look 
Acquisition  module’s  statements  in  state  1: 

S2  — ►  33 
S16  -♦  ■*! 

^17  3i 

We  find  that  the  statement  S2— >53  has  a  full  input  set  queued.  Since  only  one  statement  is 
ready  to  fire,  we  need  not  fork  multiple  simulations. 

Finally,  for  each  statement  with  complete  input  set,  we  dequeue  the  oldest  input  tokens  and 
fork  one  simulation  for  each  possible  output  set.  In  case  of  statement  sj-*S3,  we  dequeue  the 
newly  arrived  input  token  from  stream  2’s  queue.  Since  the  statement  contains  only  one  output 
set,  -*S3,  we  need  not  fork  multiple  simulations. 

We  nexi  checl  "or  an  active  invocation.  If  an  invocation  is  currently  active,  we  queue 
the  output  set  on  the  invocation  queue.  Otherwise,  we  fire  the  output  set.  In  case  of  the 
Acquisition  module,  we  find  that  no  invocation  is  c\irTently  active,  and  we  fire  the  output  set 
-»S3- 

To  fire  ein  output  set,  the  event  handler  assigns  the  output  set  to  the  active  invocation 
variable  and  queues  events  which  immediately  result  from  this  invocation.  The  verifier  queues 
one  invocation  completion  event  for  the  output  set  and  one  token  creation  event  for  each  token 
within  the  output  set.  In  queueing  these  events,  the  verifier  assumes  that  the  invocation  will 
run  to  completion  without  interruption.  This  assumption  means  that  the  invocation  wiU  not 
be  preempted  and  that  the  processing  of  newly  arrived  tokens  during  invocation  will  not  delay 
the  invocation.  As  a  result  of  this  assumption,  the  time  to  create  tokens  and  to  complete  this 
invocation  is  constant. 

To  fire  the  output  set  —^33  of  the  Acquisition  module,  the  event  handler  first  assigns  this 
output  set  to  be  the  active  invocation  of  the  Acquisition  module.  Next,  the  event  handler 
queues  one  complete-invocation  event  and  one  create-token  event  on  the  event  queue.  It  queues 
a  complete-invocation  event  at  time  9.  And  it  queues  one  create-token  event  token  for  the  only 
output  token  in  the  output  set,  along  streeun  3,  also  at  time  9. 
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For  another  example  of  a  successful  attempt  to  fire,  consider  the  arrival  of  a  token  along 
stream  3  at  time  19.  The  arrive-token  event  handler  queues  the  token  on  stream  3’s  input 
queue  and  attempts  to  fire  the  ModelSelect  module.  The  event  handler  finds  the  NodelSelect 
module  in  state  1  -  its  only  state.  It  finds  one  statement  whose  input  set  is  ready: 

S3  S4[15]Aa8[15] 

°  39(5  -  12, 10  -  15)A38[10  -  15] 

The  event  handler  forks  two  separate  simulations  -  one  for  each  output  set.  Since  the  ModelSelect 
module  is  inactive,  both  simulations  fire  their  output  set.  Figure  4.8  shows  the  state  of  the 
event  queue  in  each  forked  simulation  right  after  the  fork. 

Invocation  Completion 

A  third  type  of  an  event  is  the  complete-invocation  event.  Once  an  invocation  completes,  the 
module  becomes  idle  and  available  for  new  invocations.  We  empty  module’s  active  invocation 
variable  and  check  whether  any  invocation  is  weuting  on  the  invocation  queue. 

For  instance,  at  time  9,  the  Acquisition  module  completes  its  invocation.  We  reset  its 
active  invocation  to  empty  and  check  its  invocation  queue.  We  find  that  no  invocation  is 
wciiting  to  fire  cind  return  control  to  the  main  loop. 

4.3.4  Program’s  Execution  Model  Summary 

In  this  section,  we  have  presented  an  execution  model  for  program’s  timing  based  ca  the  abstract 
behavior  and  timing  specification  of  individual  modules,  we  have  described  this  execution 
model  in  terms  of  a  simple  sirntdator.  We  have  outlined  its  structure  zuid  illustrated  its  event 
handling.  We  will  return  to  this  simulator  in  Chapter  6  where  we  will  extend  it  in  order  to 
verify  constraints.  At  that  time,  we  will  outline  issues  of  interest  in  o\ir  design  of  a  realistic 
simulator. 


4.4  Summary 

In  this  chapter,  we  have  introduced  a  data  independent  specification  of  program’s  behavior  cind 
timing.  First,  we  specified  all  possible  behaviors  of  each  module.  Next,  we  assigned  timing 
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costs  to  each  module’s  behavior.  At  the  end,  we  used  the  behavior  and  timing  of  individual 
modules  to  derive  a  data  independent  execution  model  for  the  entire  program. 


Chapter  5 

Constraint  Specification 


Having  specified  progTcim’s  timing,  we  focus  our  attention  on  our  second  goal  -  constraint 
specification.  So  far,  our  notion  of  a  constraint  is  very  informal.  We  tedk  of  constrziints  under 
some  circumstances,  through  some  subgraphs.  In  this  chapter,  we  will  try  to  formalize  this 
notion. 

We  will  refer  heavily  to  the  program  execution  model  of  Section  4.3.  Figures  5.1  and  5.2 
show  how  we  can  use  the  execution  model  to  verify  a  simple  constraint.  In  Figure  5.1,  we  drop 
one  token  onto  stream  17  at  time  0.  In  Figure  5.2,  we  watch  SAMPLE  step  through  time.  We 
can  end  the  propagation  whenever  all  awaited  tokens  arrive  at  their  destination.  The  awaited 
tokens  are  those  tokens  whose  arrival  time  has  been  constrained.  We  refer  to  them  as  the 
constrained  tokens.  In  Figure  5.2,  we  have  ended  the  propagation  when  one  constrained  token 
cdong  stream  1  arrived  at  the  Tool  module.  Comparing  that  constrained  token’s  arrival  time 
agciinst  some  imposed  deadline  will  tell  us  whether  a  constraint  has  been  met. 

As  Figures  5.1  and  5.2  illustrate,  we  can  verify  a  simple  constraint  without  any  formal  spec¬ 
ification.  We  can  simply  visually  track  all  tokens  of  interest  through  each  step  of  a  simulation. 
In  the  next  few  sections,  we  will  get  away  from  this  cumbersome  approach. 


5.1  Simple  Constraints 

We  start  by  extracting  that  information  which  identifies  a  simple  constraint.  Consider  again 
the  constraint  of  Figure  5.1.  Here,  we  have  dropped  one  token  onto  stream  17  at  time  0.  Then 
we  stepped  through  time  until  one  token  along  stream  1  arrived  at  the  Tool  module.  We 
stopped  our  simulation  at  that  point.  The  information  we  provided  to  the  simulator  could  be 
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Figiire  5.1:  Initializing  a  Simulation. 


summarized  as: 

5i7[0]  -♦  SlTool- 

Our  summary  simply  lists  the  stream  we  dropped  a  token  onto  and  the  time  at  which  we 
dropped  it;  together  with  the  input  stream  and  the  module  at  which  we  awaited  arrival  of  a 
final  token.  An  eirrow,  indicating  propagation  of  tokens,  separated  the  dropped  initial  token 
from  the  aweiited  final  token. 

We  can  generalize  our  summary  to  any  initial  token  along  stream  s  at  time  t  and  to  any 
final  token  along  input  stream  s’  of  destination  module  M: 

s[t]  s'a,.  (5.1) 

To  confirm  or  reject  a  constraint,  we  must  compeire  the  arrival  time  of  an  awmted  token 
against  the  imposed  deadline.  Say,  in  Figure  5.2,  we  imposed  a  deadline  of  10  time  imits  on  the 
arrival  of  one  token  along  input  stream  1  of  the  Tool  module.  The  simulator’s  final  time,  10, 
would  meet  this  deadline.  We  cam  easily  incorporate  the  imposed  deadline  into  the  constraint’s 
specification: 

3i7[0]  —  3irc>oi[l0]- 

Similarly,  we  can  incorporate  a  deadline  into  the  general  specification  of  5.1: 

^  9'mW- 
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(5.2) 


Here,  we  constreun  the  arrival  time  of  a  token  along  input  stream  s'  of  module  M  to  be  less 
them  some  deadline  d. 

A  simple  extension  of  5.2  lets  us  drop  multiple  tokens  along  a  stream  at  different  times. 
An  example  of  such  a  constraint  is  the  tool  recovery  constraint.  A  recovery  signal  can  only  be 
ger^'-ated  after  two  tool  cycles.  So  to  observe  a  recovery  token  along  stream  1,  we  must  drop 
two  successive  tokens  onto  stream  2  one  cycle  time,  or  150  time  units,  apart: 

3j[0, 150]  -*  -siToo/lSOO]. 

In  general,  we  can  drop  n  tokens  onto  a  stream  at  times  ti  through 

5[ti...t„]  —  a]vf[d].  (5.3) 

By  convention,  we  drop  the  first  token  at  time  0. 

An  analogous  extension  lets  us  constrain  arrival  times  of  multiple  tokens  at  an  input  stream 
s'  to  module  M: 

s[ti...t„]  — »  s'^[di . . .  dm].  (5.4) 

Here,  we  constraun  m  successive  to!  ens  to  arrive  within  m  monotonically  increasing  deadlines 
di  through  dm- 

Finally,  the  reader  may  have  noticed  that  both  of  SAMPLE’S  constraints,  the  feedback 
constraint  and  the  tool  recovery  constraiint,  will  need  to  drop  initial  tokens  along  multiple 
streams.  This  is  so  because  stream  18,  the  acknowledgment  stream,  must  have  a  token  in  order 
to  enable  SAMPLE’S  Mod«lS«l«ct/HodelH«rg«  pair  (Section  4.1).  We  cam  extend  our  tool 
recovery  constraint  to  drop  an  additionail  token  along  stream  18  as  follows: 

32(0,  150]A3i8[0]  — ►  ■Sirooi[300]. 

In  general,  we  can  extend  5.4  to  drop  initial  tokens  along  multiple  streams: 

[^1,1  '  '  *  ]A32[t2,l  '  *  •  ^2,n2]^  •  *  * 

•S.Vf  [^1  •  •  •  ^m]-  (5-5) 

-Vncdogously,  we  can  constraiin  arrival  times  of  tokens  at  multiple  destinations: 

.  .  .  fl,ni  ]AS2[<2,1  •  •  •  ^2.nj]A  .  .  . 

-  (5.6) 
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5.2  Conditional  Constraints 


Difficulty  arises  as  constrained  paths  encounter  selector  modules.  Selector  module,  such  as  the 
MonitorMerge  module,  fire  one  of  several  output  sets  depending  on  data  values.  In  case  of  the 
HonitorHerge  module,  input  set  S12AS14  enables  one  of  two  output  sets,  —>317  or  — Having 
filled  MonitorMerge’s  input  set,  the  simiilator  forks  a  separate  simulation  for  each  output  set. 

This  may  not  be  the  correct  behavior  with  respect  to  a  given  program  constraint.  For  each 
invocation  of  the  HonitorHerge  module,  a  given  constraint  may  constrain  propagation  of  tokens 
through  one  or  through  both  output  sets.  A  constraint  which  constrains  propagation  through 
both  output  sets  is  insensitive  to  the  data  dependent  actions  of  the  HonitorHerge  module. 
Such  constraint  must  be  met  no  matter  which  output  set  the  HonitorHerge  module  selects. 

An  example  of  such  a  constraint  is  SAMPLE’S  feedback  constraint.  Using  5.6,  we  specify 
sample’s  feedback  constraint  as: 

32[0]A3i8[0]  -♦  •5irooi[150]. 

Consider  the  trace  of  feedback  constraint’s  verification.  We  drop  one  token  onto  streams  2  and 
18  at  time  0.  In  Figure  4.6,  we  watched  them  propagate.  When  a  token  arrived  at  input  stream 
3  of  the  HodelSeloct  module,  it  enables  one  of  two  threads:  — ►34A38  or  — ••239A38.  Since  we 
wished  to  constrain  a  feedback  signal  through  both  the  oil  and  the  sand  model,  we  forked  two 
simulations. 

In  contrast,  a  constraint  which  constrains  propagation  through  only  one  of  module’s  several 
output  sets  is  conditional!  on  the  data  dependent  actions  of  that  module.  We  call  such  a 
constraint  a  conditional  constraint.  SAMPLE’S  tool  recovery  constraint  (Section  3.2.3)  is  a 
conditional  constraint.  It  is  conditional  on  the  HonitorHerge  module’s  selecting  thread  — »3i7. 
To  verify  such  a  constraint,  we  need  to  inform  our  verifier  which  output  set  to  pursue. 

As  Figure  4.6  illustrated,  we  can  straightforwardly  extend  our  simulator  to  verify  conditional 
constraints.  We  simply  have  the  user  inform  the  simulator  which  threads  to  pursue  further. 
But  how  do  we  specify  conditional  constrciints  independent  of  simulation? 

First,  we  can  declare  the  selection  of  all  output  sets  to  be  the  default.  Whenever  we  do  not 
explicitly  state  otherwise,  the  simulator  will  pursue  all  av^lilable  evaluation  threads.  Under  this 
default  cissumption,  5.6  suffices  to  specify  SAMPLE’S  feedback  constraiint: 

32[0]A3i8[0]  — ►  ■»ir<x>i[l50]. 
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The  selection  of  all  threads  along  the  ModelSelect  module  has  become  implicit. 

But  we  still  need  to  express  conditioned  constraints  such  as  the  tool  recovery  constraint. 
Specifically,  we  need  to  express  the  fact  that  the  tool  recovery  constraint  applies  only  in  case 
the  MonitorMerga  module  selects  to  output  a  token  along  stream  17.  One  approach  is  to 
incorporate  MonitorHerg*  module’s  selection  into  the  simulation.  We  simply  redefine  the 
actions  the  MonitorMerge  module  for  the  purposes  of  the  tool  recovery  constraint.  We  narrow 
the  choice  of  evaluation  threads  within  its  first  invocation  to  —*317: 

state  1:  S12AS14  — ►  S17 

next  state:  state  2 


state  2:  S12AS14  -+  317 


next  state:  state  2. 

As  we  wished,  the  simulator  will  now  verify  the  tool  recovery  constraint  only  for  the  case  where 
the  MonitorMerge  module  selects  to  output  a  token  along  stream  17. 

Our  corrected  specification  of  the  tool  recovery  constraint  becomes: 


and 


32[0,  150]A3is[0]  -» 

•*irooi[300]. 

M  onitorM  erge 

state  1: 

•*12A3i4 

M  odule 

next  state: 

state  2 

Timing 

Specification 

state  2: 

•*12A*14 

next  state: 

state  2. 

•*17 


*17 


To  extrapolate,  we  can  specify  any  conditional  constraint  by  redefining  the  actions  of  some 
selector  modules.  For  successive  invocations  of  these  modules,  we  narrow  the  choice  of  output 
sets,  using  states. 


5.3  Nondeterministically  Merging  Constraints 

The  emulator  of  Figure  4.6  stiU  Ccumot  verify  some  constraints.  It  c£uinot  verify  those  con¬ 
straints  which  propagate  through  nondeterministic  merge  modules.  WTien  a  constrained  token 
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propagates  through  a  nondeterministic  merge  module,  it  may  merge  onto  the  same  stream  as 
other  unconstrained  tokens  and  lose  its  identity. 

Unfortunately,  both  of  SAMPLE’S  constraints,  the  tool  recovery  constraunt  and  the  feedback 
constraint,  propagate  through  a  nondeterministic  merge  module  -  the  Acquisition  module. 
Take  the  tool  recovery  constraint.  To  verify  this  constraint,  we  drop  two  tokens  onto  streaun 
2  at  times  0  aind  150;  and  one  token  onto  stream  18  at  time  0.  We  then  watch  these  tokens 
propagate  through  our  timing  specifications.  Figure  5.3  shows  four  snapshots  of  our  simulation. 
We  want  to  end  this  propagation  when  a  recovery  token  has  propagated  through  SAMPLE’S 
monitor  segment  (Figure  3.13)  and  reached  the  Tool  module  along  stream  1.  Unfortunately, 
two  feedback  tokens,  having  propagated  through  SAMPLE’S  model  segment  (Figure  3.15),  will 
also  reach  Tool  module  along  stream  1. 

As  Figure  5.3  illustrates,  our  simulator  gives  us  no  indication  which  of  the  three  tokens  has 
arrived.  Since  we  cannot  tell  which  of  the  three  tokens  htis  reached  the  Tool  module,  we  cannot 
teU  whether  to  end  our  simulation.  If  the  arrived  token  is  the  awaited  recovery  token,  then  we 
would  like  to  end  our  simulation  and  compeire  z  against  the  imposed  deadline.  On  the  other 
hand,  if  the  arrived  token  is  one  of  the  two  feedback  tokens,  then  we  would  like  to  continue  our 
simulation,  awaiting  a  recovery  token.  We  must  somehow  identify  the  arrived  token. 

Our  dilemma  was  brought  about  by  the  Acquisition  module.  This  module  has  nonde- 
terministically  merged  two  feedback  tokens  from  SAMPLE’S  model  segment  and  one  recovery 
token  from  SAMPLE’S  monitor  segment  onto  stream  1.  Once  on  streeim  1,  these  tokens  became 
indistinguishable.  To  recover  the  identity  of  these  tokens,  we  can  tag  them,  much  like  airport 
luggage,  as  they  enter  the  Acquisition  module. 

Figure  5.4  demonstrates  our  modified  simulation.  Here,  when  a  token  reaches  the  Acquisition 
module,  the  module  updates  the  incoming  empty  tag  to  indicate  token’s  origin.  It  specifies  that 
the  token  along  its  output  stream,  stream  1,  was  initiated  by  one  token  along  its  input  stream 
16  or  input  stream  17.  Consequently  the  tokens  arrive,  tagged  and  identified,  at  the  Tool 
module. 

In  general,  we  can  extend  our  simulator  to  update  token’s  tag  each  time  it  invokes  a  non¬ 
deterministic  merge  module,  merging  that  token  onto  a  shaued  stream^.  By  looking  at  the  tag, 
the  user  wiU  then  be  able  to  identify  each  token.  In  case  of  the  tool  recovery  constradnt  the 

‘Note  that  not  all  invocations  of  the  nondeterministic  merge  module  Acquisition  merge  tokens  onto  a  shared 
stream. 
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Time:  104 


Time:  0 


Time:  104 


2 


Figure  5.4:  Modified  Tool  Recovery  Constraint  Simulation:  Displayed  Next  to  Each  Token  is 
the  Token’s  Tag. 
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user  will  know  whether  a  recovery  token  or  a  feedback  token  has  reached  the  Tool  module. 

But  how  do  we  specify  constraints  through  non  deterministic  merge  modules  independent 
of  simulation?  As  we  have  just  seen,  in  the  presence  of  nondeterministic  merge  modules,  the 
simulator  cannot  end  simulation  whenever  some  token  arrives  at  the  final  destination.  Instead, 
it  must  await  a  token  with  the  desired  tag. 

To  specify  a  constraint  through  a  nondeterministic  merge  module  then,  we  must  specify 
the  tag  of  the  awaited  final  token.  In  general,  each  tag  wUl  consist  of  a  partiedly  ordered  set. 
Each  element  within  the  set  specifies:  a  nondeterministic  merge  module,  the  set  of  tagged  input 
tokens  which  invoked  that  module,  and  the  sh^ed  output  stream. 

The  specification  of  the  tool  recovery  constraint,  for  inst£ince,  becomes: 

S2[0,  150]Asi8[0]  — ►  :  3i7— ►si}]. 

and 


A/  onitor  Merge 

state  1: 

•*12ASi4  — *■  Si7 

Module 

next  state: 

state  2 

T  iming 

Specification 

state  2: 

•*12ASi4  — ♦  Si7 

next  state: 

State  2. 

Here,  the  constrained  token  along  input  streaim  1  of  the  Tool  module  is  tagged.  Its  tag  specifies 
that  the  token  was  once  merged  onto  a  shared  stream,  stream  1,  by  the  Acquisition  module. 
That  invocation  consumed  one  token  along  input  stream  S17. 

In  general,  we  can  expand  the  specification  of  auiy  simple  constraint  (Equation  5.6)  to  include 
tags: 

•  •  ■  il,ni]AS2[t2,l  •  •  •  f2,n,]A  •  •  • 

Aft  [<^1.1  }  •  ■  •  di^m,  }] A'»2,\f,  [<^2,1  }  •  •  •  <^2,m,  {tag2,mj  }]A  •  •  • .  (5.7) 

5.4  Summary 

In  this  section,  we  have  specified  real-time  constraints  through  feedback  processes.  Using  our 
simple  simulator,  we  first  showed  how  to  verify  a  constraint  by  stepping  through  a  simulation. 
Based  on  this  interaction,  we  extracted  information  which  defined  the  constraint.  Figures  5.6 
and  5.5  show  the  final  specification  of  SAMPLE’S  feedback  and  tool  recovery  constraints. 
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3j[0,  150]A3i8[0]  — *  sirooif^OOlAcquisitioiv :  3i7— ►Si}]. 


and 


MonitorMerge 

state  1: 

S12AS14 

Module 

next  state: 

state  2 

Timing 

Specification 

state  2: 

^12ASi4 

next  state; 

state  2. 

Figiire  5.5:  Final  Specification  of  SAMPLE’S  Tool  Recovery  Constraint. 

S2[0]Asi8[0]  -♦  3iroot[l50{Acquisition  ;  sia— si}]. 

and 

MonitorMerge  state  1: 

Module  next  state: 

Timing 

Specification  state  2: 

next  state: 

Figure  5.6:  Final  Specification  of  SAMPLE’S  Feedback  Constraint. 

With  our  constraint  specification,  we  are  now  ready  to  verify  contention  free  constraints.  We 
are  ready  to  take  program’s  constraint  specification  together  with  program’s  timing  specification 
and  verify  that  constraint.  In  the  next  Chapter,  we  will  extend  our  simulator  of  Section  4.3 
into  a  constraint  verifier  and  explore  in  greater  detail  the  design  decisions  behind  this  verifier. 


S12AS14 

state  2 


S12AS14 

state  2. 


>*17 
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Chapter  6 


Verification 

Having  finished  specification,  we  are  ready  to  tackle  our  last  goal  -  verification  of  constraints.  In 
the  previous  chapter,  we  have  used  the  simulator  of  Section  4.3  to  informally  verify  constraints. 
We  will  first  extend  this  simulator  to  accept  and  to  verify  constraints.  We  will  then  discuss 
issues  which  we  faced  in  our  more  realistic  implementation.  We  will  reevfiluate  the  need  for  an 
event-driven  verification  and  conclude  with  a  description  of  a  taggmg  scheme  which  we  used  to 
avoid  duplication  of  work  by  multiple  verifications. 

6.1  Verification 

We  need  to  make  several  minor  changes  to  the  structure  and  control  flow  of  our  simulator  in 
order  to  verify  constraints.  First,  our  verifier  must  accept  a  constraint  specification  and  initialize 
its  state  accordingly.  Second,  the  verifier  must  tag  tokens  as  they  pass  through  nondeterministic 
merge  modules  in  order  to  identify  their  path.  And  finally,  each  time  a  token  arrives,  the  verifier 
must  check  whether  the  arrival  satisfies  a  constraint. 

0.1.1  Static  Description 

The  simulator  was  initiedly  presented  with  a  static  description  of  the  program.  This  description 
embodied  all  the  information  which  we  have  accumulated  about  a  program  and  its  allocation. 
We  now  extend  this  description  to  include  constraints.  The  verifier  is  presented  with  a  formal 
specification  of  the  constraint  it  is  to  verify  (Chapter  5). 
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6.1.2  Runtime  State 

The  verifier  also  needs  two  additional  runtime  structures  to  simulate  the  passage  of  time  2ind  to 
accumulate  results.  First,  at  initialization,  the  verifier  must  create  a  place  to  record  the  arrival 
times  of  constraiined  final  tokens.  As  the  verification  begins,  the  arrival  times  of  constrained 
tokens  aie  empty.  As  the  verification  progresses,  the  arrival  times  slowly  fill  in. 

Second,  the  verifier  must  append  the  description  of  each  token  with  a  tag.  Each  token  must 
carry  a  tag  describing  its  path  through  nondeterministic  merge  modules  (Section  5.3).  Each 
time  a  module  fires,  its  output  tokens  must  inherit  the  tags  of  all  input  tokens.  In  addition, 
each  time  a  nondeterministic  merge  module  fires,  its  output  tokens  must  extend  their  tag  as  we 
saw  in  Section  5.3. 

6.1.3  Verification 

The  overall  control  flow  of  ’’he  verification  is  somewhat  more  complex  than  that  of  the  simulator. 
The  verification  first  initializes  the  verifier  based  on  the  constreunt.  It  then  loops  handling  the 
next  event.  Whenever  a  new  token  arrives,  the  verifier  checks  whether  the  constraint  has  been 
met.  The  following  sections  describe  the  two  new  components  of  this  verification;  initialization 
and  constraint  testing,  together  with  ciny  changes  to  simulator’s  individual  event  handlers. 

Initialization 

To  initialize  a  verification,  we  create  places  to  record  the  arrival  times  of  constrained  final  tokens. 
We  replace  the  specifications  of  redefined  modules.  And  finally,  we  enqueue  create-token  events 
for  all  initial  tokens. 

For  instance,  consider  initialization  of  the  feedback  constraint  verification.  Figure  5.6  gave 
a  formal  specification  of  the  feedback  constr^unt.  First,  we  create  a  place  to  record  the  arrival 
time  of  one  token  along  stream  1  at  module  Tool  whose  tag  is  Acquisition  :  sis-^si. 

Next,  we  replace  the  MonitorMerge  module’s  original  specification: 

^12^^14  ■*17 

with 
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state  1: 


next  state:  state  2 

state  2: 

next  state:  state  2. 

Finally,  we  enqueue  two  events  to  create  feedback  constraint’s  two  initial  tokens  -  one  along 
stream  S2  at  time  0  and  another  along  stream  also  at  time  0.  The  type  of  these  events 
is  create-token  signifying  that  a  token  is  to  be  created  at  time  0  along  the  specified  streams. 
These  two  events  form  the  irutial  event  queue  in  Figure  4.8: 

0  cr««t«-to)sei<  a2 
0  craat6-tok«n  alS 

Constraint  Testing 

The  original  simulator  stepped  through  time  indefinitely,  simulating  the  timing  behavior  of  a 
program.  Our  verifier,  on  the  other  hand,  should  terminate  when  all  of  constraint’s  final  tokens 
have  arrived.  Each  time  a  token  arrives  at  its  destination,  the  verifier  checks  whether  it  is  a 
filial  token.  In  terms  of  our  three  event  handlers  -  token  creation,  token  arrival,  and  invocation 
completion  -  the  verifier  extends  the  token  arrival  heindler  to  do  this  check. 

The  new  token  arrived  handler  compares  the  newly  arrived  token  against  constraint’s  fined 
tokens  which  have  not  eirrived  yet.  It  looks  for  final  tokens  along  the  same  stream,  with  the 
same  destination  modiile,  and  with  the  seime  tag.  If  the  event  handler  does  find  such  a  final 
token,  it  records  its  arrival  time. 

Take,  for  insteince,  the  feedback  constrednt  verification.  In  one  fork  of  this  verification,  a 
token  arrival  event  is  scheduled  at  time  80  along  streeun  1  at  module  Tool  with  tag  Acquisition  : 
5i6— *•*!•  The  token  arrival  h2mdler  compares  this  stream,  destination  modide,  iind  tag  against 
that  of  constraint’s  final  token  and  finds  the  two  match.  It  records  the  arrival  time  of  this  final 
token  to  be  80. 

As  the  verification  progresses,  the  arrival  times  of  const.^aint’s  final  tokens  fill  in.  Once 
aU  arrivad  times  have  been  filled,  the  verifier  terminates  the  simulation  and  checks  whether  all 
deadlines  exceed  airrival  times.  In  case  of  the  feedback  constraint,  both  forks  of  the  verifier 
terminate  successfully,  having  met  the  imposed  deadline. 
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0.1.4  Implementation  Summary 

In  this  section,  we  have  extended  the  simulator  of  Section  4.3  in  order  to  verify  constraints.  We 
have  initialized  our  simulation  based  on  its  constraint,  tagged  tokens  through  nondeterministic 
merge  modules,  and  terminated  each  simulation  once  aU  final  tokens  arrived.  Clearly,  the 
verifier  we  outlined  in  this  section  is  neither  efficient  nor  adequate.  In  the  next  section,  we  will 
discuss  issuf  of  interest  in  our  design  of  a  realistic  verifier. 

6.2  Extensions  and  Issues 

The  simple  verifier  outlined  in  the  previous  section  leaves  much  to  be  desired.  For  one,  it  does 
not  handle  resource  contention.  In  this  section,  we  wiU  outline  further  extensions  to  the  verifier. 
And  justify  some  of  the  decisions  made  in  our  implementation. 

6.2.1  Contention 

Our  verifier  of  Section  4.3  ignored  most  contention  costs.  The  verifier  acknowledged  that 
several  potenticil  invocations  could  contend  for  one  module.  However,  once  running  a  module 
invocation  was  guaranteed  to  complete  without  interruption.  Our  attempted  justification  for 
this  guarantee  pointed  to  non-overlapping  allocation.  We  allocated  each  stream  to  a  separate 
channel  and  and  each  module  to  a  sepeirate  processor. 

Unfortunately,  even  with  non-overlapping  allocation,  a  module  invocation  is  not  guaranteed 
to  rim  without  interruption.  Each  2tfriving  token  may  have  to  interrupt  the  processor  and  raise 
module’s  completion  time. 

Moreover,  a  realistic  verifier  will  need  to  handle  overlapping  allocations.  SAMPLE’S  allo¬ 
cation  is  an  example  (Figure  3.18).  With  multiple  allocations,  each  processor  emd  each  channel 
must  be  treated  as  a  resource  with  waiting  queues  and  general  allocation  methods.  Additional 
events  must  handle  processor  cind  channel  deallocation. 

6.2.2  Initial  Tokens 

Our  timing  constraint  specification  from  Chapter  5  gave  no  guideline  as  to  what  our  set  of 
initial  tokens  shoiild  be.  It  is  important  to  realize  that  we  cannot  simply  drop  those  initial 
tokens  which,  through  program’s  behavior,  will  eventually  generate  final  constrained  tokens. 
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Any  tokens  that  could  cifFect  the  timing  of  final  constrained  tokens  must  be  considered.  Other 
tokens  could  affect  timing  through  contention  for  shared  resources  or  shared  modules. 

In  general,  finding  a  sufficient  set  of  initial  tokens  must  be  left  to  the  user.  For  periodic 
progrcims  however,  the  set  of  periodically  injected  initial  tokens  could  be  defined  as  part  of  the 
prograim’s  behavior  specification.  We  leave  this  definition  for  further  work. 

6.2.3  Regeneration 

In  the  previous  chapter,  we  implicitly  assumed  a  single  regeneration  stage  given  one  set  of 
constrcimed  input  tokens.  In  other  words,  we  asstrmed  that  the  propagation  of  a  single  set 
of  constraint’s  initial  tokens  through  the  constradned  program  defined  the  steady  state  of  that 
prograun.  It  followed  that  the  state  of  the  program  before  propagation  was  equivailent  to  the  one 
following  the  propagation.  Under  this  assumption,  a  single  propagation  of  constraint’s  initial 
tokens  was  representative  of  all,  since  all  propagations  were  identical. 

This  assumption  can  be  easily  checked  and  relaxed.  Following  a  propagation,  we  check  for 
any  unconsumed  tokens  within  the  program  graph.  For  periodic  progrsuns  with  complete  set 
of  initial  tokens,  the  only  unconsumed  tokens  should  be  initialization  tokens,  such  as  the  token 
along  SAMPLE’S  acknowledgment  stream^.  If  any  other  tokens  remain  then  the  verification 
should  be  repeated  imtil  a  steady  state  is  reached. 

An  example  of  a  constraint  which  must  be  repeated  is  SAMPLE’S  feedback  constraint: 

S2[0]Asi8[0]  —  Si7’<^[300{Acquisitioii  :  si6-*3i}]. 

One  propagation  of  this  constraint’s  input  tokens  leaves  cin  unconsumed  token  along  streeim  12. 
Within  a  second  propagation,  the  HonitorH«rg«  module  consumes  this  token  together  with  one 
along  stream  14.  The  feedback  constraint  is  met  only  if  both  propagations  meet  the  imposed 
deadline. 

6.2.4  Constant  Latency 

Our  simple  verifier  substituted  the  maximum  possible  latency  for  each  latency  ramge.  This 
substitution  wais  not  realistic.  In  addition  to  data  dependent  ranges  of  Table  4.3,  parameters 
such  ais  broadcast  charmel  contention  point  to  latency  distributions  rather  than  latency  con¬ 
stants.  The  verifier  assumed  that  by  using  the  maximum  possible  latencies  along  the  way,  it 

‘  It  might  be  useful  to  specially  identify  initiaiiiation  tokens  in  constraint  specification. 
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would  find  the  maximum  possible  latency  through  the  entire  constrcuned  path.  Unfortimately, 
this  assumption  bre^lks  down  in  the  presence  of  contention  for  shared  resources  or  for  shared 
modules. 

We  illustrates  the  fallacy  of  this  assumption  on  the  simple  progreim  of  Figure  6.1.  The 
timing  behavior  of  the  three  modules  in  Figure  6.1  is; 


Ml  behavior; 

3 

^3[3] 

M2  behavior; 

2-4 

S4[2  -  4; 

M3  behavior; 

•S3 

10 

55(10] 

S4 

10 

55(10] 

Assume,  for  simplicity,  that  all  chaimels  have  zero  latency  and  each  module  is  allocated  to 
a  separate  processor.  The  imposed  constraint  is; 

Ji[0]AS2[0]  ►  ^5M(ie*tinationll5{M3  .  S3  >S5}j. 

Figures  6.1  and  6.2  show  the  inadequacy  of  verification  beised  on  maximum  latencies.  Using 
the  maximiun  latencies  along  modxiles,  we  find  that  the  constrained  final  token  j>jTives  at  time 
13,  well  within  the  deadline.  Using  the  minimum  latencies  instead,  we  see  that  the  constrained 
final  token  will  not  eirrive  untU  time  22. 

One  solution  would  be  for  our  verifier  to  fork  one  verification  for  each  permutation  of 
overlapping  ranges.  This  could  be  very  costly.  A  much  less  computationally  intensive  solution 
is  to  enforce  as  many  maximum  latencies  as  possible  at  runtime.  Whether  we  need  to  or  not, 
we  promise  to  wait  until  the  maximum  latency.  In  case  of  module  M2,  for  instance,  we  promise 
to  generate  a  token  and  terminate  at  time  4.  This  is  the  approach  we  adopt  in  this  chapter.  A 
more  desirable  solution  would  be  to  find  a  boimd  on  the  introduced  deviation  from  maximum 
latency. 


6.3  Alternative  to  Event-Driven  Verification 

Our  verifier  was  event  driven.  The  advantage  of  this  approach  was  accmate  simulation  of  state 
at  each  point  in  time.  For  each  decision,  the  simulator  presented  an  accmate  snapshot  of 
computation  state  at  the  time  of  the  decision.  The  disadvantage  of  this  approach  was  the  cost. 
To  step  through  events  sequentially  in  time,  we  had  to  maintain  and  sort  an  event  queue. 
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! 
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Figure  6.1:  Verification  Using  Maximum  Latencies. 
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Figure  6.2:  Verification  Using  Minimum  Latencies. 


An  alternate  approach  would  be  to  eliminate  the  event  queue.  Instead  of  queueing  each 
new  event  and  handling  events  in  order,  we  cotild  handle  events  recursively  -  regardless  of  their 
time.  We  wiU  refer  to  this  modified  verifier  as  the  unordered  verifier.  For  instance,  the  new- 
token  creation  hamdler  would  not  return  control  to  a  main  loop.  Instead  of  enqueueing  an 
arrive-token  event  at  a  later  time,  it  would  invoke  the  token  arrival  handler  right  away.  Control 
w-ould  return  to  the  top  level  only  when  a  sequence  of  events  terminated. 

Figiu-e  6.3  illustrates  on  a  verification  of  the  feedback  constraint.  It  shows  the  order  in  which 
events  cire  handled  by  our  modified  verifier.  We  see  that  events  up  to  time  149  are  handled 
before  an  event  at  time  0.  Surprisingly,  the  unordered  handling  of  events  did  not  effect  the 
correctness  of  this  verification.  All  events  and  their  times  are  identical  to  those  of  Figure  4.8. 

This  is  not  always  the  case.  In  the  next  few  sections,  we  will  look  at  ways  in  which  the 
absence  of  event  ordering  could  compromise  the  correctness  of  our  verification.  Not  surprisingly, 
we  wdl  find  that  any  source  of  nondeterminism  in  our  programming  model  cannot  be  simulated 
correctly  by  an  unordered  verifier.  In  addition,  contention  costs  can,  at  best,  be  bound. 
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0  create-token  82 

♦ 

4  arrive-token  s2  Acquisition 

♦ 

9  complete-invocation  Acquisition 

♦ 

9  create-token  s3 

♦ 

19  arrive-token  s3  ModelSelect 

♦ 

9  arrive-token  s3  MonitorSelect 

♦ 

19  complete-invocation  MonitorSelect 

♦ 

19  create-token  sll 

♦ 

19  arrive-token  sll  Monitorl 

♦ 

149  complete-invocation  Monitorl 

♦ 

109  create-token  sl2 

♦ 

109  arrive-token  sl2  Mon  torMerge 

♦ 

0  create-token  slS 

♦ 


Figure  6.3:  Part  of  a  Unordered  Verification  of  the  Feedback  Constraint. 
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0.3.1  Nondeterminism 


First,  we  look  at  ways  in  which  nondeterminism  in  our  programming  model  could  compromise 
the  correctness  of  our  verification.  There  are  three  sources  of  nondeterminism  in  Stream  Mci- 
chine  programs.  All  three  originate  from  nondeterministic  merge  modules  and  their  extension, 
the  generalized  merge  modules  (Section  4.1).  In  terms  of  our  abstract  behavior  specification,  all 
three  originate  from  the  presence  of  multiple  statements.  Next,  we  examine  each  of  the  three 
sources  of  nondeterminism  and  consider  how  the  presence  of  each  affects  the  correctness  of  an 
unordered  verification. 

Multiple  Statements 

The  first  source  of  nondeterminism  is  caused  simply  by  the  presence  of  multiple  statements. 
Take  the  simplest  set  of  two  statements: 


•si  — 

32  —  S4 

The  order  in  which  individual  statements  are  invoked  depends  on  the  order  in  which  tokens 
arrive  along  input  streams.  That  is,  the  order  of  invocations  is  time  dependent  or  nondeter¬ 
ministic. 

Time  dependent  order  of  invocations  compromises  the  behavior  of  miilti-state  modules  in 
an  unordered  verification.  As  later  input  tokens  axe  hcindled  first,  they  may  fire  the  wrong 
statement  first  and  wrongly  propel  the  module  into  its  next  state. 

Consider  a  modxile  with  the  following  behavior: 


state  :  1 

— ‘  •*3 

—  is 

neztstate  : 

:  2 

state  :  2 

^2 

—  i* 

neztstate  ; 

:  2 

Say  that  one  token  arrives  along  stream  1  and  sometimes  later  one  token  arrives  along  strecim  2. 
Fig’ire  6.4  illustrates.  From  the  module’s  timing  behavior,  the  arrival  of  a  token  along  stream 
I  will  fire  statement  si— *53  £md  transfer  the  module  into  state  2.  Later  in  state  2,  the  arrival 
of  a  token  along  stream  2  will  fire  the  statement  Sj— *54. 
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Consider  what  happens  if  we  handle  the  arrival  of  a  token  along  stream  2  first  (Figure  6.5). 
The  arrival  of  a  token  along  stream  2  will  wrongly  invoke  the  32— '^3  statement  and  wrongly 
transfer  the  module  into  state  2.  Later  on  in  state  2,  a  token  will  arrive  along  stream  1  and 
remain  queued  forever.  Clezirly,  the  module’s  behavior  will  be  compromised. 

si  32  si  s2  si  32  si  s2 

II  11  M  M 
TT  FT  n  11 

33  s4  sS  34  83  34  s3  s4 

Figure  6.4:  Correct  Verification, 
si  s2  si  32  3l  32 

11  II  11 

IT  n  ri 

33  34  s3  34  33  s4 

Figure  6.5:  Unordered  Verification. 

Shared  Output  Stream 

A  second  source  of  nondeterminism  is  caused  by  the  sharing  of  a  common  output  stream 
by  several  statements.  The  simplest  merge  module: 

31  — ♦  S3 

32  — ►  33 

in  Figure  3.4  illustrated.  The  order  in  which  tokens  are  merged  onto  the  output  stream  depends 
on  the  order  in  which  tokens  arrive  ^dong  input  streams  Left  zind  Right.  The  order  of  tokens 
along  the  output  stream  is  therefore  nondeterministic. 

Two  difficulties  arise  as  a  result  of  misordered  handling  of  tokens  edong  shared  output 
strecuns.  The  handling  of  tagged  tokens  cind  the  timing  of  successive  modules’  invocations  are 
compromised. 

Tagging  First,  the  behavior  of  tagged  constreiints  is  compromised.  To  illustrate,  consider  the 
program: 
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Ml  behavior: 

100 

33[100] 

M2  behavior: 

10 

34I10] 

M3  behavior: 

33 

10 

35[10] 

34 

10 

35(10] 

M4  behavior: 

35A36 

10 

37(10] 

M5  behavior: 

37 

10 

The  imposed  constraint  is; 

J6[0]Aji[0]Aj2[0]  JrM5[20{M3  :  34— 35}]. 


Figure  6.6  shows  the  progress  of  this  verification.  Since  tokens  arrive  at  stream  5  imordered,  the 
invocation  of  module  M4  may  consume  the  wrong  token.  As  a  result,  the  imposed  constraint 
win  go  unmet. 


Unordered  Verification. 


s5 


Invocation  Times  Even  if  constreiined  fineJ  tokens  do  not  contain  tags,  the  timing  of  our 
program  may  be  compromised.  This  is  because  module  invocations  may  consume  wrong  tokens 
amd,  as  a  result,  fire  at  the  wrong  time.  Figure  6.6  illustrated  this.  Module  M4  consumed  the 
wrong  token  along  stream  5  aind,  as  a  result,  fired  at  time  110  instead  of  20.  It  is  important 
to  notice  that  invocation  times  in  our  unordered  verification  are  guairanteed  to  equal  or  exceed 
the  correct  invocation  times.  Constraiints  will  not  be  compromised  because  of  these  incorrect 
invocation  times,  although  they  may  go  needlessly  unmet. 
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Overlapping  Input  Streams 

A  final  source  of  nondeterminism  is  caused  by  the  sharing  of  a  common  input  stream  by 
several  statements.  Take  the  case: 


3iAS2  — "  •*3 

Si  -►  S4 

Depending  on  the  time  at  which  an  input  token  arrives  at  stream  1,  its  arrival  can  complete 
one  or  both  input  sets.  The  number  of  input  sets  it  completes  is  nondeterministic. 

The  time  dependent  number  of  completed  input  sets  can  cause  incorrect  behavior.  To 
illustrate,  consider  the  module: 


S1AS2  — *•  33 


^2  ^  ^3 


As  before,  say  one  token  arrives  along  stream  1  and  sometimes  later  one  token  arrives  along 
stream  2.  If  we  handle  arriving  tokens  in  order,  the  first  token  will  queue  onto  the  input  queue 
of  stream  1.  The  second  token  along  stream  2  will  complete  both  input  sets.  Which  input  set 
will  actually  fire  is  nondeterministic  and  our  verifier  will  fork  a  separate  verification  for  each 
case  (Figure  6.7). 

If  we  handle  arrived  tokens  out  of  order,  the  module  will  behave  incorrectly  (Figure  6.8). 
A  token  along  stream  2  will  complete  only  one  input  set  and  fire.  Later  on  a  token  will  arrive 
and  queue  indefinitely  onto  the  input  queue  of  stream  1. 

Summary  of  Nondeterminism  in  Unordered  Verification 

In  this  section,  we  have  identified  modules  for  which  an  unordered  verification  is  not  feasi¬ 
ble.  All  such  modules  behave  nondeterministically.  As  events  are  handled  out  of  order,  their 
nondeterministic  behavior  is  compromised. 

0.3.2  Contention 

An  additional  phenomenon  compromises  the  correctness  of  an  imordered  verification  -  con¬ 
tention.  In  case  of  module  contention,  the  verifier  must  be  able  to  tell  whether  auiother  invo¬ 
cation  is  occupying  a  module.  In  case  of  resource  contention,  the  verifier  must  be  able  to  tell 
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si  32 


s3 

Figure  6.7:  Correct  Verification, 
si  32  si  32  si  s2 

♦  V  ♦ 

sS  sS  s3 

Figure  6.8:  Unordered  Verification. 

whether  another  consumer  is  occupying  the  resource.  But  events  are  handled  unordered,  the 
verifier  does  not  have  €ua  accurate  snapshot  of  the  program’s  current  state. 

Module  Contention 

Our  prograimining  model  dictates  that  each  naodule  have  at  most  one  invocation  at  any  given 
time.  An  event  driven  verifier  maintained  this  constraint  by  setting  the  current  allocation 
variable  while  a  module  was  invoked.  An  imordered  verifier  cam  maintain  the  same  constraint 
by  recording  the  most  recent  completion  time  for  each  module.  If  another  invocation  fires  before 
the  completion  time,  its  invocation  latency  will  be  increased  by  the  remaining  completion  time 
of  the  previous  invocation.  This  procedure  will  guarantee  at  most  one  invocation  of  each  module 
at  a  time. 

But  it  will  not  guarantee  the  correct  order  of  invocations.  As  we  have  seen,  the  presence 
of  nonucterministic  modules  will  compromise  the  invocation  order.  Figrire  6.6  eilso  illustrates 
this.  Since  the  arrival  of  tokens  along  streams  Z  and  4  will  be  handled  out  of  order,  the  two 
invocations  of  module  M4  will  be  switched.  The  invocation  S4— ^ss  will  incorrectly  have  to  wait 
for  the  invocation  S3— >^5  to  complete. 
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Resource  Contention 


The  order  and  time  of  consumers’  allocations  will  not  be  preserved.  In  our  event  driven  verifier, 
each  consumer  must  compete  with  adl  other  consumers  at  that  time  for  a  resource.  To  allocate 
a  processor  or  a  channel,  we  must  know  exactly  which  consumers  have  arrived.  Without  this 
knowledge,  we  wiU  not  be  able  to  compute  the  correct  time  when  a  consumer  will  acquire  its 
resource. 

This  problem  is  more  serious  than  that  of  module  contention.  In  the  absence  of  nondeter¬ 
minism,  we  could  compute  the  time  it  takes  an  invocation  to  acquire  a  module.  But  we  cannot 
compute  the  time  it  takes  an  invocation  to  acquire  a  processor. 

Fortunately,  in  the  absence  of  nondeterminism,  we  cam  compute  a  time  which  equals  or 
exceeds  the  correct  time  to  acquire  a  resource.  To  do  that,  we  look  at  adl  consumers  which  will 
ever  compete  for  a  given  resource.  We  accumulate  these  by  simulating  the  program’s  behavior 
independent  of  time.  For  each  consumer,  we  cam  then  make  the  unreadistic  assiunption  that 
it  acqmres  the  module  laist.  This  aissumption  is  guaranteed  to  equal  or  exceed  the  correct 
invocation  time^. 

Summary  of  Contention  in  Unordered  Verification 

To  conclude,  in  the  absence  of  nondeterministic  modules,  a  ’mordered  verifier  can  handle  con¬ 
tention  costs.  It  cam  compute  the  exact  time  it  takes  an  invocation  to  acquire  a  module.  And, 
by  accumulating  all  consumers  for  each  resoiuce  first,  the  verifier  cam  place  an  upper  bound  on 
the  time  it  tadces  a  each  consumer  to  acquire  that  resource.  However,  constraints  met  by  the 
program  may  not  be  verified  because  of  unreaHsticadly  high  upper  bounds. 

0.3.3  Alternative  Summary 

In  this  section,  we  have  looked  at  ways  in  which  unordered  event  handling  might  produce 
incorrect  results.  We  saw  the  presence  of  nondeterministic  modules  compromised  the  timing, 
amd  even  behavior  of  an  unordered  verifier.  Even  in  the  absence  nondeterministic  modules,  we 
saw  that  resource  contention  costs  could  only  be  bound. 

’We  can  tighten  the  aasuznpticn  by  eliminating  all  consumer.^  which  ate  guaranteed  to  follow  a  given  consumer. 


88 


6.4  Tagged  Verification  to  Avoid  Duplication  of  Verification 


In  this  section,  we  address  the  overhead  of  multiple  simulations.  The  event-driven  verifier  copied 
aU  runtime  state  (Section  4.3)  each  time  it  forked  multiple  verifications.  We  will  look  at  an 
alternative  way  to  manage  multiple  verifications. 

As  we  saw  in  Section  4.3,  the  event-driven  verifier  forked  multiple  verifications  in  two  places. 
Whenever  the  verifier  fired  a  statement  with  multiple  output  sets,  it  forked  one  simulation  for 
each  output  set.  Each  output  set  represented  different  timing  behavior.  To  validate  a  constreiint, 
each  possible  timing  behavior  had  to  be  verified. 

In  addition,  generalized  merge  modifies  coifid  cause  the  verifier  to  fork  multiple  verifications. 
Say  the  cirrival  of  one  token  completed  severafi  input  sets.  Which  input  set  should  consume  the 
token?  The  programming  model  did  not  specify.  Without  am  accurate  knowledge  of  the  Stream 
Machine  implementation  that  is  being  verified,  the  verifier  had  to  fork  multiple  verifications  - 
one  for  each  completed  input  set. 

The  forking  of  multiple  verifications  may  lead  to  redimdancy.  Consider  again  our  saimple 
prograim  with  each  modifie  aind  each  streaun  afilocated  to  a  separate  processor  or  channel.  Fig¬ 
ure  4.6  showed  the  verifier  forking  two  simifiations  as  a  result  of  HodalS«l«ct  module’s  multiple 
output  sets: 


— ►  s^Asg 
— >•  2S9A3g 

Figure  4.8  showed  the  outstanding  events  at  each  point  in  time.  Notice  that  two  identical  events 
appear  in  each  forked  verification:  the  coi.iplete-invocation  event  and  the  create-token  event  for 
MonitorSelect  aind  its  output  token  along  stream  11.  As  a  result,  each  of  the  two  verifications 
goes  on  to  verify  am  identical  monitor  subgraph  of  SAMPLE. 

This  duplication  of  work  arises  because  our  verifier  needlessly  copies  the  entire  runtime  state 
when  forking.  As  a  result,  events  whose  behavior  and  timing  do  not  depend  on  the  fork  will  be 
verified  multiple  times. 

An  altemate  approach  is  to  share  state  among  multiple  verifications.  Figure  6.9  illustrates. 
Instead  of  duplicating  the  entire  runtime  state,  the  verifier  tags  each  piece  of  runtime  state.  In 
Figure  6.9,  tag  tagi  identifies  all  runtime  state  which  is  belongs  to  the  — ♦S4A38  branch.  Tag 
tag2  identifies  all  runtime  state  which  belongs  to  the  — »2s9As8  branch.  Note  that  there  are  two 
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distinct  invocations  of  the  ModalSalect  module  •  one  for  each  branch.  On  the  other  hand,  a 
single  invocation  of  the  Monitorl  module  is  shared  by  both  branches. 

Figure  6.10  shows  the  single  shared  event  queue  at  each  point  in  time  up  to  the  fork. 
Comparing  Figure  6.10  to  Figure  4.8,  we  see  that  the  tagged  verifier  simply  tagged  zdl  events 
when  it  forked  two  verifications.  It  tagged  events  imique  to  the  —^s^Ass  bramch  with  tag  tagl, 
events  unique  to  the  — ►239AJ8  brainch  with  tag  tag2,  and  events  shared  by  both  branches  with 
both  tags. 

A  natural  question  to  ask  is  what  does  the  next  step  of  Figure  6.10  look  like.  Ignoring  tags, 
we  know  how  the  simple  verifier  of  Sections  4.3  and  6.1  would  behave.  But  how  do  tags  ciffect 
this  behavior? 

0.4.1  Tagged  Verifier 

In  this  section,  we  outline  chainges  made  to  the  simple  verifier  in  order  to  handle  tags. 

Tagged  State 

As  we  have  seen  in  Figure  6.10,  the  tagged  verifier  tags  each  piece  of  runtime  state  with  the 
verifications  to  which  that  state  belongs.  Each  token  carries  a  tag  identifying  the  verification(s) 
to  which  that  token  belongs.  We  will  call  this  tag  the  verifications- tag  to  differentiate  it  from 
the  tag  described  in  Section  5.3.  The  tag  described  in  Section  5.3  identifies  the  origin  of  a 
token  which  has  passed  through  nondeterministic  merge  modules.  It  has  no  relation  to  the 
verification- tag. 

All  initial  tokens  start  out  as  peirt  of  the  same  verification.  As  a  result,  they  all  share  the 
same  initial  verification  tag. 

Each  module  carries  a  list  of  tagged  current  states.  Since  each  verification  has  to  be  in  some 
module  state,  each  module  carries  as  many  tagged  current  states  as  there  aire  verifications. 
Each  module  also  carries  a  list  of  tagged  current  invocations  -  one  for  each  verification  which 
is  currently  invoking  that  module. 

Finally,  as  we  saw  in  Figure  6.10,  each  event  carries  a  verification-tag  identifying  the  verih- 
cation(s)  within  which  that  event  is  pending. 
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Time:  0 


Time:  4 


0  create-token  »2 

0  create-token  al8 

1 

4  arrive-token  s2  Acquisition 

0  create-token  sl8 

4  arrive-token  a2  Acquisition 

1 

- 

— 

0  arrive-token  sl8  ModelSelect 

4  arrive-token  s2  Acquisition 

Time:  9 

Time:  19 

9  complete-invocation  Acquisition 

9  create-token  s3 

i 

19  arrive-token  s3  ModelSelect 

19  complete-invocation  MonitorSelect 

19  create-token  sll 

L 

9  create-token  s3 

i 

-* 

— 

9  arrive-token  s3  MonitorSelect 

19  arrive-token  s3  ModelSelect 

Time:  19  (cont.) 

Time:  19  (cont.) 

- 

19  complete-invocation  MonitorSelect  tagl  tag2 

19  create-token  sll  tagl  tag2 

31  create-token  s9  tag2 

34  create-token  s9  tag2 

34  create-token  88  tag2 

34  create-token  a4  tagl 

34  create-token  sS  tagl 

39  complete-invocation  ModelSelect  tagl 

39  complete-invocation  ModelSelect  tag2 

- 

•> 

Figure  6.10:  Events  for  Part  of  Tagged  Feedback  Constraint  Verification. 
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Event  Handling 


Simple  Events  Each  event  is  now  part  of  some  verification(s)  specified  by  its  verification 
tag.  Consequently,  each  event  should  only  consider  runtime  state  which  corresponds  to  its 
verification(s).  Take  the  remaining  events  at  time  19  after  the  fork  in  Figure  6.10  -  the  invocation 
completion  of  the  MonitorSalsct  module,  the  creation  of  a  token  along  its  output  stream  11. 
and  eventually  its  arrival  at  the  Monitorl  module.  All  three  events  are  part  of  two  verifications, 
the  tagl  verification  and  the  tag2  verification.  The  tagged  event  handler  handles  these  events 
the  same  way  as  the  individual  untagged  event  handlers  for  verification  tagl  cind  for  verification 
tag2  would  have.  Figures  6.11  aind  6.12  show  the  state  of  our  verifier  and  of  its  event  queue 
before  after  these  three  events  -  right  cifter  the  fork  at  time  19  and  at  the  end  of  time  19. 


tagl,  tag 


Figure  6.11:  Part  of  Tagged  Feedback  Constraint  Verification. 

To  complete  invocation  of  the  HonitorSelect  module,  the  event  handler  empties  the  current 
invocation  Vciriable  for  verifications  tagl  and  tag2.  It  cdso  checks  whether  a  new  invocation  is 
queued  to  run  in  verification  tagl  or  in  verification  tag2.  Since  both  verifications  have  an  empty 
invocation  queue,  the  event  handler  returns  control  to  the  main  loop.  The  creation  of  a  token 
along  stream  11  triggers  am  ’aurive- token  event.  Since  the  token  was  created  in  verifications 
tagl  and  tag2,  the  token  aurives  at  Monitorl  in  verifications  tagl  amd  tag2.  The  arrival  of  a 
token  along  stream  11  invokes  the  Monitorl  module  in  verifications  tagl  and  tag2.  This  is  the 
state  of  our  verifier  at  time  31  in  Figure  6.11. 

A  more  illustrative  point  occurs  at  time  41.  Figures  6.13  and  6.14  illustrate.  A  token  arrives 
at  the  input  stream  10  of  the  Nod«lH«Tg«  module  in  verification  tag2.  At  this  point  two  tokens 
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Figure  6.12:  Events  for  Part  of  Tagged  Feedback  Constraint  Verification. 

are  queued  at  the  input  stream  8  -  one  in  verification  tagl  and  one  in  verification  tag2.  In 
verification  tag2,  a  complete  input  set  is  present  and  an  invocation  of  the  ModelHerge  module 
is  fired.  The  input  token  along  strecun  8  in  verification  tagl  stays  intact. 

Multiple  Forks  In  the  previous  section,  we  have  seen  how  tagged  state  is  handled.  But  what 
happens  when  the  tagged  event  handler  encoimters  another  fork? 

This  happens  in  the  verification  of  the  recovery  constraint  (Figure  5.4).  At  time  150  a 
second  initial  token  is  injected  into  stream  2.  At  time  169,  the  ModelSelect  module  forks  ^or 
the  second  time.  The  module  forks  within  two  verifications  -  the  tagl  verification  and  the  tag2 
verification.  As  a  result,  the  forking  event  handler  sees  all  state  marked  tagl  or  tag2.  As  was 
the  case  in  the  first  fork,  the  event  handler  labels  all  (visible)  state  as  belonging  to  one  or  both 
forks. 

For  instance,  a  final  token  along  sireaun  1  was  part  of  a  single  ve?  ification  -  tag2.  After  the 
fork,  this  token  becomes  part  of  two  verifications  -  tag2-tag3  and  tag2-tag4. 

In  our  example  in  (Figure  5.4),  all  state  is  visible  to  the  forking  event  handler.  In  general, 
this  need  not  be  the  case.  Had  a  nested  fork  occmred  inside  verification  tagl,  all  state  inside 
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Time;  41 


tagi,  tag2 


Figure  6.13:  Part  of  Tagged  Feedback  Constraint  Verification. 


41  arrive-Coken  slO  ModelMerge  tag2 

44  complete-invocation  Sand  tag2 

44  complete-invocation  Oill  tagl 

44  create-totaen  sS  tagl 

109  create-tolcen  812  tagl,tag2 

149  complete-invocation  Monitorl  tagl.tag2 


i 


44  complete-invocation  Sand  tag2 

44  complete-invocation  Oill  tagl 

44  create-toloen  s5  tagl 

61  complete-invocation  ModelMerge  tag2 

61  create-token  816  tag2 

109  create-toloen  812  tagl,tag2 

149  complete-invocation  Monitorl  tagl,tag2 


Figure  6.14:  Events  for  Part  of  Tagged  Feedback  Constraint  Verification. 
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Time:  150 


Time:  169 


verification  tag2  would  have  remained  unaffected.  The  final  token  along  streaim  1  marked  tag2 
would  have  remained  marked  tag2. 

6.4.2  Modified  Tagged  Verifier 

Unfortunately,  the  tagged  verifier  described  so  far  in  this  section  does  not  reduce  the  cost  of 
forking  multiple  verifications.  Just  like  the  simple  verifier,  the  tagged  verifier  touches  erch  piece 
of  runtime  state  when  forking.  The  simple  verifier  touched  each  piece  in  order  to  copy  it.  The 
tagged  verifier  touches  each  piece  in  order  to  extend  its  tag  if  necessary. 

.A.  modified  version  of  the  tagged  verifier  can  significantly  lower  the  cost  of  forking  multiple 
verifications.  The  original  tagged  verifier  tagged  each  piece  of  runtime  state  with  the  identity 
of  all  verification  branches  in  which  it  existed.  A  modified  version  tags  each  piece  of  runtime 
state  with  the  identity  of  all  verification  branches  in  which  it  does  not  exist. 

This  modification  eliminates  the  need  to  touch  each  piece  of  runtime  state  when  forking. 
Since  each  existing  piece  of  rtmtime  state  will  exist  in  both  branches  of  the  fork,  its  tag  does 
not  change.  Only  the  immediate  outcome  of  each  branch  must  be  tagged  to  indicate  that  it 
does  not  exist  in  its  sibling  branch. 

0.4.3  Tagged  Verification  Summary 

We  have  outlined  the  implementation  of  a  tagged  event-driven  verifier.  Unlike  the  simple  event- 
driven  verifier  of  Section  4.3,  this  verifier  does  not  needlessly  duplicate  verifications  at  each  fork. 
Instead,  it  tags  each  piece  of  runtime  state  as  belonging  (or  in  case  of  the  modified  version  not 
belonging)  to  certain  verification  branches.  As  a  result,  the  tagged  verifier  avoids  verifying  the 
same  subgraph  multiple  times. 

We  have  implemented  the  modified  tagged  verifier  as  peirt  of  this  work.  Further  work  is 
needed  to  evaluate  its  usefulness  for  various  types  of  programs.  The  tagged  verifier  avoids  the 
cost  of  copying  runtime  state  auid  needlessly  duplicating  work  at  each  fork.  However,  in  return 
it  incurs  the  cost  of  tag  manipulation  at  each  event. 
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Chapter  7 

Conclusion 


At  the  beginning  of  this  project,  we  were  presented  with  a  distributed  programming  environ¬ 
ment  for  control  and  data  acquisition  in  the  wireline  industry.  We  were  told  of  a  need  to 
guarantee  a  specific  program  response  within  a  strict  time  bound.  We  narrowed  our  problem 
by  concentrating  on  a  specific  program  allocation. 

One  possible  way  to  guaraintee  such  response  is  by  runrang  the  program  for  a  set  of  input 
values  which  cover  cdl  possible  response  times.  We  rejected  this  approach  for  several  reasons. 
First,  our  domain  might  not  guarantee  repeatable  response  times.  Certain  latencies  might  vary 
within  a  range.  Second,  access  to  the  exact  runtime  environment  -  a  wireline  truck  -  is  limited 
during  the  program  development  stage.  Third,  the  control  flow  of  our  programs  is  expected  to 
reach  complexity  level  at  which  selection  of  sufficient  input  values  is  no  trivial.  And  fourth,  the 
expected  granulcirity  of  our  timing  costs  is  high  enough  to  miike  simulation  feasible. 

As  a  result,  we  opted  for  simulation.  We  clearified  our  notion  of  a  program  to  a  point  where 
we  could  simulate  all  possible  timing  costs.  And  we  clarified  our  notion  of  a  program  response 
to  a  point  where  we  could  verify  whether  a  particular  program  response  will  take  place  within 
a  strict  time  boimd  As  with  most  projects,  much  rem£uns  to  be  accomplished.  The  following 
two  sections  offer  our  ideas  for  improvements  and  future  directions. 

7.1  Improvements 

We  see  two  major  areas  for  improvement,  both  in  our  program  specification. 


98 


7.1.1  Linking  Behavior  of  Modules 

To  achieve  data  independence,  our  module  behavior  specification  abstracted  away  veJues  along 
tokens.  We  could  no  longer  tell  which  values  along  input  tokens  produced  each  set  of  output 
tokens.  Similarly,  we  could  not  tell  which  values  along  input  tokens  lead  to  each  possible  latency 
of  an  output  token  or  an  invocation.  At  the  level  of  a  module,  this  abstraction  succeeded  in 
describing  all  possible  timings  and  behaviors  of  that  module. 

However,  at  the  program  level  this  abstraction  removed  useful  information.  Our  execution 
model  was  imawcire  of  ainy  correlation  between  modules’  timings  and  behaviors.  It  simulated 
every,  potentiadly  infeasible,  permutation  of  modules’  possible  timings  and  behaviors.  As  a 
result,  a  constraint  could  be  falsely  rejected  if  some  infeasible  permutation  of  modules’  possible 
timings  and  behaviors  could  not  meet  the  constraunt. 

Any  future  work  should  specify  alignment  between  individual  modules’  timings  and  be¬ 
haviors.  As  we  suggested  in  otir  summary  to  Section  4.1,  users  could  enforce  such  alignment 
through  tags. 

7.1.2  Specification  of  Periodic  Input 

We  relied  on  constraint  specification  to  describe  the  initial  state  of  a  verification  through  an 
input  set.  As  we  discussed  in  Section  6.2.2,  selection  of  a  sufficient  initial  s^t  is  affected  by 
contention  costs  and  so  depends  on  a  particular  allocation.  In  retrospect,  a  cleaner  approach 
would  have  been  to  specify  periodic  input  as  prirt  of  modules’  behavior  and  timing  specification. 

7.2  Future  Directions 

We  focused  our  interest  in  this  project  on  a  single  known  program  allocation.  A  naturad 
expansion  of  our  work  would  be  the  development  of  an  allocator.  Our  verifier  could  be  utilized 
by  a  heuristic  driven  allocator.  Development  of  proper  heuristics  which  take  into  account  read- 
time  constraints  in  our  domain  is  an  important  field  for  further  research. 
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